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INTELLIGENT TERMINAL APPLICATION PROTOCOL 

BACKGROUND 

The invention relates to communications systems, and more particularly 
to techniques, including a protocol, for effecting supplementary services in a 
communications system. 

It is known to provide a wide variety of services to users of various 
types of telephone equipment. To access this type of service, the user can establish a 
connection with a service node (SN), which can be a switch or computer with or 
without switching capability. In many systems, an application program running in the 
SN uses the voice channel for sending voice prompts and tones to the telephone. The 
voice channel is also utilized in the reverse direction for sending dual-tone multi- 
frequency (DTMF) digits from the telephone to the SN. In such a system, it is not 
required that the telephone include any intelligence; the dialogue is entirely between 
the user and the SN, whereby the user listens to voice prompts and tones, and 
responds by pressing keys on the telephone. Consequently, the telephone is 
transparent to the communication and cannot support the user in any way. 

More advanced services are known as well. Such services include 
provision of an 800 Services Database, a Credit Card Verification Database, 
Geographic Call Routing, Incoming Call Routing, Multilocation Extension Dialing, 
Network Automatic Call Distribution, Flexible Call Routing, Flexible Carrier 
Selection, and others. In wireline telephone systems, such enhanced subscriber 
services may be provided through an Intelligent Network (IN) (e.g., Bellcore 
Advanced Intelligent Network (AIN) or its CCITT/ITU equivalent: ITU's CS-1, 
Q.1200, etc.). 

In wireless communications systems, enhanced subscriber services may 
be provided by an intelligent mobile station (also called "intelligent terminal"), such 
as that which is described in U.S. Patent Application No. 08/617,139, entitled 
INTELLIGENT MOBILE STATION FOR A CELLULAR 

TELECOMMUNICATIONS NETWORK, filed on March 18, 1996 (Attorney Docket 
No. 1000-0022), which is hereby incorporated by reference herein. Some enhanced 
services may alternatively be provided by an intelligent mobile station working in 
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cooperation with a SN. To accomodate different services, the computer in the SN 
may include a wide variety of resources, such as various interface and switching 
units, facsmile units, voice processing units, an e-mail interface, computer network 
interfaces, modem resources and data storage. These resources are controlled by 
5 software that interacts with software in the intelligent terminal. The SN may be a 
single user solution or a multi-user solution with one or a number of interacting SNs. 

The interaction between the SN and the intelligent terminal takes place 
via a communications link which is herein referred to as a control channel. The 
control channel can be established as a modem connection on the voice channel, or 

10 may alternatively be established on a separate communication link. FIGS. la-Id 
illustrate possible arrangements for a SN to facilitate the provision of services to a 
user of a cellular or ordinary fixed telephone. 

FIG. la illustrates a case where a cellular telephone 101 includes a 
modem 103 and software 105 for providing one or more services. A SN 107 that 

15 includes software 109 and a modem 111 is also provided in the system. It is possible 
to establish a communications link between the cellular telephone 101 and the SN 107 
by means of a cellular network 113 and any other network 115 (e.g., a public or 
private network). The SN 107 may be part of the other network 115 as shown, or 
may be part of the cellular network 113, or can even be added to one of these 

20 networks as an overlay solution (i.e., in the same way that a private access branch 
exchange (PABX) is connected to a public network). The two modems 103, 111 
provide a mechanism for the physical transmission of information between the service 
node 107 and the cellular telephone 101 to take place. The information flows between 
the SN's software 107 and the cellular telephone's software 105. 

25 FIG. lb shows an alternative arrangement that is substantially the same 

as that depicted in FIG. la except for the fact that the cellular telephone no longer 
includes its own modem 103. Instead, this facility is provided inside the radio base 
station 117. From the point of view of the software 105 inside the cellular telephone, 
however, there is no difference in the sense that service-related information still flows 

30 between the SN's software 107 and the cellular telephone's software 105. 
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FIG. lc shows an arrangement for providing service to an ordinary 
fixed analog telephone 119. Here, the fixed telephone 119 is connected to a modem 
resource 121 that also includes software 123 for providing one or more services. 
Another difference from the previously described arrangements is the substitution of a 
5 fixed network 125 for the cellular network 113. In all other respects, this 

arrangement functions like the arrangements of FIGS, la and lb, with the SN's 
software 111 exchanging information with the software 123 as required for providing 
the various services. 

Yet another arrangement is shown in FIG. Id. Here, a fixed digital 

10 telephone 127 is tied directly to a fixed digital network 129 without the need for any 
modem. The SN 107, which includes the software 109, is also tied directly to the 
fixed digital network 129. The SN's software 111 exchanges information with the 
software 123 as required for providing the various types of service. 

It can be seen from the above that the SN 107 and the "service 

15 telephone" (e.g., any of the celular or fixed telephones 101, 119, 127) must have 
interacting software and the same modem capability. This is most efficiently 
supported by two different communication protocols: one higher level protocol 
(henceforth referred to as an "application protocol") for supporting the interacting 
software (or service software) communications and a lower level protocol for 

20 supporting the communication between the modems. This layering of protocols is 

depicted in FIGS. 2a and 2b. The layering of protocols is generally known in the art, 
and is not described here in greater detail. 

FIG. 3 shows the possibility of supplying a single SN 107 with 
interfaces to different telephones 301, 303, 305, 307 even if the user is one person 

25 and the calling party only calls one telephone number to the SN 107. The software 
309 in the SN 107 can page the user on different telephone numbers (unknown to the 
calling party). 

The nature of the new services that will use the control channel requires 
that the application protocol be open to supporting new functions and/or services. 
30 However, some implementations of the control channel provide only a limited 
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bandwidth for conveying the information associated with these new functions and/or 
seri vices. Consequently, an effective aplication protocol is highly desirable. 

In the ETSI recommendatesions for the pan-European GSM system, 
phase 2, there are specified a number of supplementary services which can 
5 complement and modify both teleservices and bearer services. For example, there are 
services for barring or forwarding calls and services for toggling between two 
connected calls. In addition to the standardized GSM supplementary services, mobile 
network operators are experiencing an increasing demand for operator-specific 
service. 

10 For an operator to be able to implement operator-specific services, it is 

necessary to have a generic mechanism for user interaction between a service 
application in the network and a mobile station. 

In GSM today, there is a generic mechanism for providing 
userinteractin between a service application in the netowrk and a mobile station. This 

15 mechanism is called "Unstructured Supplementary Services Data" (USSD). What is 
described about USSD in the following text is valid for USSD according to GSM, 
phase 2. USSD also exists in GSM, phase 1, but the dialogue handling is more 
limited. 

Refering to FIG. 4, in the GSM switching system, USSD is a part of 
20 the well-known "Mobile Application Part" (MAP) protocol 401. In the air interface, 
the USSD operations are carried by the layer 3 "Register", "Facility" and "Release 
Complete" messages 403. 

The USSD service application can reside in the Mobile services 
Switching Center / Visitor Location Register (MSC/VLR) 405, in the Home Location 
25 Register (HLR) 407, or in an external Mobile Service Node (MSN) 409. If a USSD 
service application is implemented in an MSN, an extension of the MAP-protocol, 
"USSD to external node" should be used. 

The USSD operations are generic and send text transparently through 
the network. Text received from a service application in the network is displayed by 
30 the MS 411. Correspondingly, the user keyboard input from the MS 411 is 
transparently sent to the service application in the network. 
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USSD has a dialogue structure. A dialogue could be initiated by the 
service application in the network, or alternatively by the MS 411. A USSD dialogue 
can exist independently of whether there is a parallel speech connection or not. 

If the network service application initiates a USSD dialogue, it invokes 
5 a Request or Notify operation. When the MS 411 has received, from the network 
service appliation (e.g., the USSD appl 1 in the MSC/VLR 405), a USSD Request 
operation containing a text string to be displayed, the MS 411 displays this text. The 
input string from the user is returned n the result operation to the network service 
application. It is also possible for the network service application to invoke a USSD 
10 Notification operation, containing text to be displayed. The difference between 

Request and Notification is that no response from the user is required in the case of 
Notification. Only an acknowledge operation is returned to the network service 
application. 

The user of the MS 411 is also able to initiate a USSD dialogue by 

15 performing a specified Man Machine Interface (MMI) input. When this input has 
been performed, the MS 411 invokes, to the network, a "Process Unstructured USSD 
Request" operation containing the input from the user. This MMI input should 
contain a unique service code which identifies the application to the network and 
makes it possible to route the operati to the correct network node. Then, the network 

20 service application can reply with a result operation, containing text to be displayed. 
The network service application can then terminate the dialogue. It is also possible 
for the network service application to continue the dialogue by invoking a USSD 
Request or Notify operation. After the reply has been received from the MS 411, the 
network service application may continue the dialogue by invoking more USSD 

25 Request or Notify operations. 

A USSD service example will now be described with reference to FIG. 
5. At step 501, a user enters the service code for information services into his MS 
411. In response, the MS 411 issues a Proc USSD request invoke (user input=USSD 
serv code) to the HLR, MSC/VLR or External node 551 in which both the USSD 

30 service provider 553 and the service application 555 are located (step 503). The 
USSD service provider 553 receives the Proc USSD request invoke, and passes the 
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pertinent command and parameter information up to the service application 555. For 
the remainder of this description, the service application 555 will be referenced as the 
recipient and source of messages received from and sent to the MS 411. However, it 
will be recognized that these messages pass through the lower layer USSD service 
5 provider 553. 

The service application 555 passes a response back to the USSD service 
provider 553, which in turn transmits a USSD request invoke ("INFO 

SERV<LF> lWeather<LF>2 TeleNum ") back to the MS 411 (step 505). This 

causes the MS 411 to display the received text to the user. 

10 In this example, the user selects "Weather" by entering 1 and pressing 

the YES key on the MS 411 (step 507). This causes the MS 411 to transmit a USSD 
request result (user input = 1) to the service application 555 (step 509). 

In response, the service application 555 causes a USSD request invoke 
("WEATHER <LF> Enter area:") message to be sent to the MS 411 (step 511). 

15 After this new text is displayed to the user, the user enters (in this 

example) 046 and presses the YES key on the MS 411 (step 513). This causes a 
USSD reuest result (user input = 046) to be transmitted to the service application 555 
(step 515). The interaction between the service application 555 and the user of the 
MS 411 continues in this fashion until the service has been provided and the 

20 connection is broken. 

It can be seen from the above that USSD works as a user interaction 
mechanism for simple operator-specific services, but that it has some drawbacks, 
especially when more advanced services need to be implemented. These drawbacks 
include: 

25 1. Long response times due to low bandwidth (300-600 bits/sec), 

inefficient coding (short message service (SMS) 7-bit alphabet) and the fact that all 
service logic must reside in the service application in the network because the MS 411 
is an unintelligent terminal. For example, an MS menu must be sent to the MS each 
time it needs to be displayed to the user. Also, the user selection must be sent to the 

30 network service application where a logical decision is made. Thus, communication 
speed between the application service provider and the MS is critical to a good 
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response time. However, as stated above, USSD has a low bandwidth in the range 
300-600 bits/sec. Generally, a limited bandwidth communications means is one that 
cannot operate at rates higher than about 1000 bits/sec. 

2. The MS user interface for services using USSD is primitive and 
5 the normal MS MMI paradigm can not be used. For example, if the service contans 

menu handling, each menu-option must be identified by a digit (or other alphanumeric 
character). The user returns the digit (or other alphanumeric character) that 
corresponds to the selected option. This way of handling menus is not user-friendly 
and gives a menu-paradigm that differs from other menus in the MS 411. 
10 Also note that this user interface cannot be utiliszed if the MS 

411 supports a graphical user interface. 

3. Local MS functions can not be utilized by USSD services. For 
example, no intelligent call handling can be performed and access to the local 
telephone book (number to name translation) is not possible. 

15 4. Timers in the network limit the length of life for USSD 

services. 

5. Limited length of the text strings sent between the MS 411 and 
the service application 555 in the network. 

6. In the MS 411, only one USSD dialogue at a time can be active. 

20 

Other strategies for user interaction are known. These include: 
Analog Display Services Interface (ADSI): This is a 
communication protocol for bi-directional transmission of data betseen a "Stored 
Program Controlled Switching system (SPCS, "service node") and an Analog Display 
25 Services Customer Premises Equipment (CPE, " terminal" ). The data transmission 
can be performed over the voice path using FFSK and DTMF. 

The design of ADSI is based on having loadable service logic in 
the terminal. However, ADSI has the limitatino in that it specifies the whole protocol 
stack in the fixed network, that is, it is not bearer independent and it can not be used 
30 as an application protocol above USSD. 
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The WWW-HTTP/HTML concept used by Internet WWW- 
servers and clients: The main problem with the WWW-concept is the reuired 
bandwidth. WWW requires at least a 9.6 Kbits/s data channel, while the average 
throughput for a USSD connection is in the range of 300-600 bits/s. If a data channel 
5 is used as the bearer instead of USSD, then no parallel speech connection could exist. 
Also, WWW s based on a strictly client server concept. There is no way for the 
server to start the interaction between the client and the server. 



10 SUMMARY 

It is therefore an object of the present invention to provide a mechanism 
for effecting supplementary services in a communications system. 

It is a further object of the present invention to provide a protocol for 
effecting supplementary services in a communications system. 

15 It is still a further object of the present invention to provide a protocol 

for effecting supplementary services in a communication system having a band-limited 
channel between a service node and the recipient of the supplementary services. 

In accordance with one aspect of the present invention, the foregoing 
and other objects are achieved in a communications system that includes a service 

20 node connected to an intelligent terminal by means of a limited-bandwidth 

communications means. In accordance with one aspect of the invention, a service is 
provided to a user of the intelligent terminal by, in the service node, analyzing an 
event to determine a primitive; using the limited bandwidth communications means to 
send a message to the intelligent terminal, wherein the message instructs the 

25 intelligent terminal to execute a routine corresponding to the primitive; and in the 

intelligent terminal, responding to the message by executing the routine corresponding 
to the primitive. 

In another aspect of the invention, the message further includes 
parameters; and the step of executing the routine corresponding to the primitive 

30 includes using the received parameters. 
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In still another aspect of the invention, the step of executing the routine 
includes the step of presenting information to the user of the intelligent terminal. 

In yet another aspect of the invention, the step of executing the routine 
includes the step of changing a state of the intelligent terminal. 
5 In still another aspect of the invention, the event is receipt of a message 

from the intelligent terminal, wherein the message indicates that the user pressed a 
particular key on the intelligent terminal. 

In another aspect of the invention, the event is detection by the service 
node of an occurrence of something that affects the intelligent terminal. The 
10 occurrence may be, for example, an incoming call directed at the intelligent terminal 

In still another aspect of the invention, the step of, in the intelligent 
terminal, responding to the message by executing the routine corresponding to the 
primitive comprises the steps of, in the intelligent terminal, determining that execution 
of the routine requires the presence of a state table that is not presently stored in the 
15 intelligent terminal; using the limited bandwidth communications means to send a 
message from the intelligent terminal to the service node, wherein the message 
requests the state table; using the limited bandwidth communications means to send 
the requested state table from the service node to the intelligent terminal; and in the 
intelligent terminal, using the received state table to execute the routine. 
20 In yet another aspect of the invention, the intelligent terminal 

additionally performs menu-handling input and output functions between the intelligent 
terminal and the user without communicating with the service node. 

In another aspect of the invention, intelligent terminal user input and 
output functions are controlled in accordance with a man-machine interface paradigm 
25 that is independent of the service being provided. 

In another aspect of the invention, a service is provided to a user of the 
intelligent terminal by performing the steps of, in the intelligent terminal, analyzing 
an event to determine an action to be taken; using the limited bandwidth 
communications means to send an operation to the service node, wherein the operation 
30 corresponds to the action to be taken and instructs the service node to execute a 

routine corresponding to the operation; and in the service node, performing the action 
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corresponding to the operation, and returning a result of the operation to the 
intelligent terminal via the limited bandwidth communications means. 

In still another aspect of the invention, providing the service further 
comprises, in the intelligent terminal, initiating a first session with the service node 
5 via the limited bandwidth communications means in response to detection of an 
incoming call at the intelligent terminal. 

In another aspect of the invention, the step of initiating the first session 
with the service, node comprises the step of negotiating between the intelligent 
terminal and the service node to ensure that resources that are to be used by the 
10 intelligent terminal and the service node are consistent with respect to one another. 

In yet another aspect of the invention, the step of initiating the first 
session with the service node includes the step of indicating a type of coding that is to 
be used in communications between the intelligent terminal and the service node. In 
one embodiment, the type of coding is Basic Encoding Rules (BER). In another 
15 embodiment, the type of coding is Packed Encoding Rules (PER). 

In still another aspect of the invention, a second session is initiated 
between the intelligent terminal and the service node while maintaining the first 
session. 

In another aspect of the invention, providing the service further 
20 comprises the step of sending an image description from the service node to the 
intelligent terminal, wherein the image description defines operations that are to be 
performed by the intelligent terminal. 

In yet another aspect of the invention, the step of using the limited 
bandwidth communications means to send an operation to the service node comprises 
25 mapping the operation onto an "Unstructured Supplementary Services Data" protocol 
data unit. In an alternative embodiment, the step of using the limited bandwidth 
communications means to send an operation to the service node comprises mapping 
the operation onto a Short Message Service protocol data unit. 

In another aspect of the invention, the step of using the limited 
30 bandwidth communications means to send an operation to the service, node comprises 
mapping the operation onto a protocol data unit of a lower layer protocol. 
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In yet another aspect of the invention, providing the service further 
comprises the steps of performing a local service function in the intelligent terminal 
without requesting assistance from the service node. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The objects and advantages of the invention will be understood by 
reading the following detailed description in conjunction with the drawings in which: 

FIGS. la-Id illustrate possible arrangements for a service node to 
facilitate the provision of services to a user of a cellular or ordinary fixed telephone; 

FIGS. 2a and 2b illustrate a layering of protocols in a communication 

system; 

FIG. 3 depicts the possibility of supplying a single SN with interfaces 
to different telephones even if the user is one person and the calling party only calls 
one telephone number to the SN; 

FIG. 4 illustrates a GSM switching system in which USSD is included 
as a part of the well-known "Mobile Application Part" (MAP) protocol; 

FIG. 5 illustrates a USSD service; 

FIG. 6 is a block diagram depicting the relationship between a SN and 
an intelligent terminal, as well as a number of components thereof, in accordance with 
one embodiment of the invention; 

FIGS. 7a, 7b and 7c depict a flow chart that illustrates exemplary 
interactions between a user, an intelligent terminal and a SN; 

FIGS. 8 and 9 are flow charts depicting the possibility for activity to be 
initiated by the SN; 

FIGS. 10a, 10b and 10c are flow charts depicting the downloading of 
an application into an "empty" intelligent terminal; 

FIG. 11 is a block diagram of a SN in accordance with one aspect of 

the invention; 

FIG. 12 illustrates a GSM network in which the inventive intelligent 
terminal application protocol (ITAP) is used for providing a service to an IMS; 

FIGs 13a through 13e illustrate an example of an ITAP service; 
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FIG. 14 depicts the use of a limited number and size of operations sent 
between the SN and the IMS in order to obtain reasonable response times, in 
accordance with one aspect of the invention; 

FIG. 15 illustrates the use of loadable ITAP image descriptions in 
accordance with one aspect of the invention; 

FIG. 16 depicts an exemplary image description for a menu of options; 

FIGS. 17 and 18 depict an exemplary technique for mapping ITAP 
operations. on the parameter "USSD string" in the USSD operations according to GSM 
phase 2, in accordance with one embodiment of the invention; 

FIGS. 19-51 illustrate ITAP operation scenarios utilizing USSD 
(according to GSM phase 2) as a bearer; 

FIGS. 52 through 57 illustrate scenarios relating to incoming call 

selection; 

FIGS. 58 through 61 illustrate scenarios involving mailbox-related 
services, in accordance with one embodiment of the invention; 

FIGS. 62 and 63 illustrate scenarios involving the updating of a routing 
table in accordance with one embodiment of the invention; and 

FIG. 64 illustrates a scenario relating to new message notification using 
ITAP, in accordance with one embodiment of the invention. 

DETAILED DESCRIPTION 

The various features of the invention will now be described with 
respect to the figures, in which like parts are identified with the same reference 
characters. 

A first embodiment of the invention will now be described with respect 
to FIG. 6, which is a block diagram depicting the relationship between a SN 603 and 
an intelligent terminal 601, as well as a number of components thereof. 
Implementation of an application (e.g., an advanced service) is divided into two parts, 
one residing in the intelligent terminal 601 and the other residing in the SN 603. In 
one aspect of the invention, the two parts of the application utilize an application 
protocol to communicate over a control channel 605. 
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The application part that resides in the intelligent terminal 601 is 
defined and implemented with the following application building components: State 
and State Tables 607; Primitives 609; Control Messages to the Terminal 611; 
Messages from the Terminal 613; and Terminal Registers 615. These components 
will now be described in greater detail. 

State and State Table 607 

The terminal will alwaus be in a defined state when running the 
application. A state is defined by a state table 607, specifying information displayed 
to the user 617, any time supervision of the state, and action to take as a result of a 
stimulus from the user 619. 

In one aspect of the invention, the transition from one state to another 
may be handled by a primitive 609. A state table 607 defines the state concerning: 

The information that will be presented to the user 617 (e.g., 
shown on a display of the terminal). 

Any menu that will be presented to the user, including a 
definition of the options that are available to the user. 

For every relevant user action (e.g., pressing a key 601 on the 
intelligent terminal 601), a primitive 609 that is to be called. 

Time supervisions of the state and the primitive to call when the 

time expires. 
Primitives 609 

There is an Application Programming Interace (API) in the intelligent 
terminal 610, wherein the API is associated with a set of primitives 609. These 
primitives 609 may be called directly from the code (e.g. , in the startup sequence, 
through a state table 607 or remotely from the SN 603). 

A primitive may have none, one or several parameters. 



Control Messages to the Terminal 611 
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A set of control messages are defined for transmission from the SN 603 
to the intelligent terminal 601. The control messages 611 may cause data to be stored 
in a terminal register 615, or may alternatively call a primitive 609. A control 
message 611 that orders a change of state is a call to a primitive. 

5 

Messages From the Terminal 613 

The intelligent terminal 601 may send one or more messages to the SN 
603 from a called primitive 609. 

There may be some specialized messages, each having a unique 
10 meaning. There may also be a generic message that reports an event to the SN 603. 
The event reporting message may include parameters indicating the current state and 
the event (e.g., an indication that key "x" was pressed, or that the state supervision 
time has expired). The intelligent terminal 601 should leave the decisino of 
appropriate measure to the SN 603 when sending such a message. 

15 

Terminal Registers 615 

The terminal registers 615 should contain data that is specific to the 
intelligent terminal 601, such as terminal identity, or data that is personal to the user 
or temporary. The user or the SN 603 should be responsible for updating terminal 
20 registers 615. 

Exemplary interactions between a user, an intelligent terminal 601 and 
a SN 603 will now be described with reference to the flow chart depicted in FIGS. 
7a, 7b and 7c. It is assumed, in this example, that the intelligent terminal 601 is 

25 presently in state SI (step 701). At step 703, the intelligent terminal 601 detects that 
the user has pressed an input key, designated key k. In response, the primitive 609 
corresponding to key k in state SI is identified and called (step 705). 

The event (i.e., the user's pressing key k while the terminal is in state 
SI) may or may not be an event that should be reported to the SN 603. If it is not 

30 ("no" path out of decision block 707), then processing continues at decision block 

723. If it is a reportable event, ("yes" path out of decision block 707), then the called 
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primitive reports the event to the SN 603 (step 709), and the intelligent terminal 601 
waits for a response (step 711). 

The SN 603 detects receipt of the event report (step 713) and responds 
by analyzing the event (step 715). The analysis determines which primitive the 
5 intelligent terminal 601 should next execute, and the SN 603 orders a call to this 
primitive (step 717), by means of the application protocol that is used on the control 
channel 605. 

The intelligent terminal . 601 receives the communication from the SN 
603 (step 719), and calls the primitive (i.e., the intelligent terminal 601 executes a 

10 stored routine designated by the primitive) (step 721). Execution continues to 
decision block 723. 

Either as a result of execution of the primitive corresponding to key K 
in state SI ("no" path out of decision block 707) or alternatively as a result of 
execution of the primitive ordered by the SN 603 (step 721), the intelligent terminal 

15 may or may not be required to change state (decision block 723). If no change of 
state is required ("no" path out of decision block 723), then a determination is made 
regarding whether new information needs to be presented to the user (decision block 
725). If so, then the new information is presented to the user (step 727), and the 
terminal remains in state SI (step 729). Otherwise ("no" path out of decision block 

20 725), no new information is presented to the user, and the terminal simply remains in 
state SI (step 729). 

Returning now to decision block 723, if it is determined that the 
terminal needs to change its state ("yes" path out of decision block 723), then it is 
determined whether the state table 607 for state S2 is presently stored in the intelligent 

25 terminal 601 (decision block 731). In general, when an intelligent terminal 601 is 
programmed for an application, the relevant state tables 607 are downloaded into the 
intelligent terminal 601, either by connecting a data base directly to the intelligent 
terminal 601, or alternatively through the network from the SN 603. If the 
application is changed, one or more state tables 607 can be downloaded from the SN 

30 603. 
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If the application needs more state tables 607 than can be stored in the 
intelligent terminal 601, a missing state table can be downloaded immediately from 
the SN 603 on demand when the intelligent terminal is going to enter that state. This 
can be done both when the intelligent terminal 601 is connected to the SN 603 and 
5 when the intelligent terminal 601 is "off-line". 

Storage of the missing state table 607 within the intelligent terminal 601 
can be temporary (i.e. , for only so long as the intelligent terminal remains in the 
corresponding state). Alternatively, the missing state table 607 can be put on a stack 
with a number of other state tables 607. To make room for the new state 607 table in 
10 the stack, a replacement strategy can be utilized in which the state table 607 that has 
been unused for the longest time will be replaced. 

It is also possible to initiate or change the application by downloading 
new primitives, either as object code or as calls to other primitives. 

Returning now to the flow chart of FIG. 7b, if the state table 607 for 
15 state S2 is stored in the intelligent terminal 601 ("yes" path out of decision block 
731), then state S2 is entered (step 743), and information regarding state S2 is 
presented to the user (step 745). The intelligent terminal 601 is now in state S2 (step 
747). 

If, however, the state table 607 for state S2 is not already stored in the 
20 intelligent terminal 601 ("no" path out of decision block 731), then a request for a 
state table 607 corresponding to state S2 is sent from the intelligent terminal 601 to 
the SN 603 (step 733). The application protocol is used on the control channel 605 in 
order to convey this request. 

The SN 603 detects receipt of the request for the state table 607 (step 
25 737), locates the requested state table 607, and downloads the state table 607 to the 
intelligent terminal 601 (step 739). Again, the downloading of the state table 607 
utilizes the application protocol on the control channel 605. 

The intelligent terminal 601 receives the state table 607 for state S2 
(step 741), and continues its processing at step 743, in which state S2 is entered. 
30 Information regarding state S2 is then presented to the user (step 745). The intelligent 
terminal 601 is now in state S2 (step 747). 
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In the above examples, all of the activity was initiated in response to a 
user action (e.g., the user pressing key K). It is also possible for activity to be 
initiated by the SN 603, as illustrated in the flow charts of FIGS. 8 and 9. 

Referring first to FIG. 8, it is assumed that the intelligent terminal is 
5 initially in state S. The SN 603 detects the occurrence of an event that affects the 
intelligent terminal 601 (step 801). The event may be, for example, an incoming call 
or a new message. In response, the SN 603 analyzes the event (step 803). The 
analysis determines which primitive the intelligent terminal 601 should next execute, 
and the SN 603 orders a call to this primitive (step 805), by means of the application 
10 protocol that is used on the control channel 605. 

The intelligent terminal 601 receives the communication from the SN 
603 (step 807), and calls the primitive with any received parameters (i.e., the 
intelligent terminal 601 executes a stored routine designated by the primitive) (step 
809). 

15 In this example, it is assumed that the intelligent terminal 601 is not 

required to change its state. Consequently, new information is presented to the user 
(step 811). For example the display portion of the intelligent terminal 601 may be 
updated with new information. The terminal then remains in state S (step 813). 

An event that is first detected by the SN 603 may also result in a 

20 change of state of the intelligent terminal 601. Referring now to FIG. 9, it is 

assumed that the intelligent terminal is initially in state SI. The SN 603 detects the 
occurrence of an event that affects the intelligent terminal 601 (step 901). The event 
may be, for example, an incoming call or a new message. In response, the SN 603 
analyzes the event (step 903). The analysis determines which primitive the intelligent 

25 terminal 601 should next execute, and the SN 603 orders a call to this primitive (step 
905), by means of the application protocol that is used on the control channel 605. 

The intelligent terminal 601 receives the communication from the SN 
603 (step 907), and calls the primitive with any received parameters (i.e., the 
intelligent terminal 601 executes a stored routine designated by the primitive) (step 
'30 909). 
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In this example, it is assumed that the intelligent terminal 601 change 

its state by enterring state S2 (step 911). Consequently, information of state S2 is 

presented to the user (step 913). For example the display portion of the intelligent 

terminal 601 may be updated with new the information of stte S2. The terminal then 
5 remains in the new state, state S2 (step 915). 

The examples presented above in FIGS. 7a-c, 8 and 9 illustrate the 

possibilities of letting the intelligent terminal 601 work in various levels of autonomy 

with respect to the SN 603. The autonomy of the intelligent terminal 601 can range 

between the following extremes: 
10 - Operation of the intelligent terminal 601 is completely 

autonomous: the intelligent terminal 601 engages in an interactive dialogue with the 

user without any established control channel to the SN 603 being utilized. 

It is also possible to let the SN 603 take over the control 

completely and provide theinformation that will be presented to the user. In this case, 
15 every state in the state table 607 indicates that every event detected by the intelligent 

terminal 601 must be reported to the SN 603. 

Since the application is defined in the intelligent terminal 601 by means 

of state tables 607 and terminal registers 615, it is easy to download a complete 

application in the terminal through the network. The new application may be 
20 downloaded into an intelligent terminal 601 that ony has a bootstrap program loaded. 

Alternatively, the new application may be downloaded into an intelligent terminal 601 

to replace another application. 

The downloading of an application into an "empty" intelligent terminal 

601 will now be described with reference to the flow chart depicted in FIGS. 10a, 
25 10b and 10c. It is assumed that the user has a predefined password and the telephone 

number for contacting the SN 603. The SN 603 has the application of the user, the 

terminal identity, and an expected password of the user. 

The intelligent terminal 601 is initially turned off. In response to the 

user turning on the terminal (step 1001), the intelligent terminal 601 begins running a 
30 boot strap application program (step 1003), which should preferably be loaded in a 

nonvolatile memory. The boot strap program causes the following steps to take place: 
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The intelligent terminal 601 uses an output device on the intelligent 
terminal 601 (e.g., a display screen) to prompt the user for information about how to 
access the SN 603 (step 1005). The information may be, for example, a telephone 
number for establishing a connection to the SN 603. The intelligent terminal then 
5 waits for a response from the user (step 1007). 

In response to the user enterring the requested information (step 1009), 
the intelligent terminal 601 calls the SN 601 through the network (step 1011). A data 
channel (e.g., a modem connection) is then established (step 1013). The intelligent 
terminal then uses the established data channel to send an application request, 
10 accompanied by the terminal identity of this intelligent terminal 601 (step 1015). In 
order to get a secure connection, the "hand-shaking" and sending of terminal identity 
may be performed in a message dialogue with several coded messages. After sending 
the application request, the intelligent terminal 601 waits for a response. 

On the SN 603 side of this process, the SS 603 receives and answers 
15 the incoming call from the intelligent terminal 601 (step 1019), and establishes its side 
of the data channel (e.g., modem connection) (step 1021). The SN 603 then uses the 
received terminal identity to find the corresponding user data (step 1023). Next, the 
SN 603 sends a request for password to the intelligent terminal 601 (step 1025). 

In reponse to receipt of the request for password, the intelligent 
20 terminal 601 prompts the user for the password (step 1027) and waits for user action 
(step 1029). The prompt to the user may either be stored in the intelligent terminal 
601 or sent from the SN 603 in the request. 

In response to the user entering the password (step 1031), the intelligent 
terminal 601 sends the password to the SN 603 (step 1033) and waits for a response 
25 (step 1035). 

In response to receipt of the password, the SN 603 compares the 
received password with one that it has stored for this user (step 1037). Assuming that 
the received password is the correct one, the SN 603 sends an acknowledge message 
to the intelligent terminal 601 (step 1039). 
30 In response to receipt of the acknowledge message, the intelligent 

terminal 601 prompts the user to wait for service initiation (step 1041), and then waits 
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for downloading to begin (step 1043). The prompt to the user may either be stored in 
the intelligent terminal 601 or alternatively sent from the SN 603. 

The SN 601 then downloads the application data to the intelligent 
terminal 601 (step 1045). The intelligent terminal 601 stores the received application 
5 data (step 1047), and then waits for further downloading (step 1049). 

The SN 601 then downloads the state tables to the intelligent terminal 
601 (step 1051). The intelligent terminal 601 stores the received state tables (1053), 
and then waits for further downloading (step 1055). 

The SN 601 then sends the intelligent terminal 601 an indication that 
10 the application has been downloaded (step 1057). In response to the received 

indication, the intelligent terminal 601 prompts the user that the application is ready 
(step 1059) and then waits for action (step 1061). The user prompt may be an audible 
and/or visible message stored in the intelligent terminal 601 or sent from the SN 603. 

The SN 603 then orders the intelligent terminal 601 to enter state 1 
15 (step 1063), and waits for a service request (step 1065). In response to receipt of the 
order, the intelligent terminal 601 presents the information of state 1 to the user (step 
1067), and then remains in state 1 (step 1069). 

The downloading of new state tables 607 and the generic service 
independent event-reporting message from the intelligent terminal 601 makes it easy 
20 to introduce new applications without having to change the application protocol or 
reprogramming the intelligent terminal 601. 

The arrangement described above is advantageous in that the location of 
the functionality is not fixed. It can be easily moved between the SN 603 and the 
intelligent terminal 601. When a new function is introduced, it can initially be 
25 located in the SN 603, and then later be stored in the intelligent terminal 601 as one 
or more new states 607. 

The location of functionality can be optmized based on the following 

considerations: 

Processor and storage capacity in the SN 603 and in the 
30 intelligent terminal 601. 

Transmission capacity of the control channel 605. 
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Amount of information that will be presented to the user. 
Any requirement for performing parts of, or an entire, function 
in the intelligent terminal 601 in a stand-alone mode without an established control 
channel 605 to the SN 603. 
5 - The frequency with which the function is used. 

The above-described arrangement is also advantageous in that it is easy 
to change the functionality of a system consisting of a SN 603 and an intelligent 
terminal 601. This may be done because: 

The system is used in another application. 
10 - The applicatin has been developed further and new functin s 

have been added. 

Several users use the same intelligent terminal 601 and have 
personal user interfaces of the same application. 

A user wants to change the functionality of his/her application. 

15 

Another embodiment of the invention will now be described. In this 
alternative embodiment, an application protocol above the USSD protocol is provided 
which makes it possible for an operator to implement more advanced services. To 
facilitate understanding of the invention, this embodiment will be described in the 

20 context of a mobile communications system environment. However, it will be 

understood by those having ordinary skill in the art that the techniques described here 
are not restricted only to mobile communications sy terns, but instead are equally 
applicable to other types of communications systems. Thus, references to mobile 
terminals, cellular communications system components such as MSC/VLR, HLR, and 

25 the like should not be construed as limitations on the scope of the invention, but 
merely as examples in which the inventive techniques are embodied. 

In this embodiment, the service application logic resides in both a 
network node (e.g, a SN) and in an intelligent terminal such as the intelligent mobile 
station (IMS) which is described in U.S. Patent Application No. 08/617,139, entitled 

30 INTELLIGENT MOBILE STATION FOR A CELLULAR 

TELECOMMUNICATIONS NETWORK, filed on March 18, 1996 (Attorney Docket 
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No. 1000-0022), which was incorporated by reference above. The protocol by which 
the application logic and the intelligent terminal communcate with one another is 
refered to herein as the "Intelligent Terminal Protocol" (ITAP). As mentioned above, 
communications between the SN and the intelligent terminal utilize a layered protocol, 
5 in which ITAP is a bearer-independent layer that is conveyed by means of a lower 
layer protocol, such as the USSD protocol according to GSM phase 2, or short 
message service (SMS). The IMS user communicates with a service node that 
contains the requested services. The ITAP connection is independent of whether or 
not there is a parallel speech connection. 
10 ITAP features include the following: 

Service independence. ITAP is a generic protocol. It is possible 
to use an IMS, supporting ITAP, for any type of personal communication service. 

No changes in the IMS software are required for service 
modifications and service additions. This means that all software modifications 
15 needed when a service is modified or a new service is introduced are only performed 
in the network service node. No changes of the IMS software is necessary. 

Bearer independence. This includes the fact that ITAP 
communications do not rely on the existence of a speech connection in the bearer. 

ITAP is optimized for a slow speed bearer. Because the 
20 available bearers include USSD and SMS (which are slow bearers), the ITAP protocol 
is optimized so that reasonable response times for the user are achieved. 

Both graphical and text based intelligent mobile stations are 

supported. 

The ITAP concept is applicable for standardization. 
25 - The service node is the data master. 

Operator service management is uncomplex. It is easy for 
operators to manage the introduction of new services and to update existing services. 

FIG. 11 is a block diagram of a SN 1101 in accordance with one aspect 
of this embodiment of the invention. The SN 1101 may comprise computer 
30 equipment that is executing one or more software programs which are organized in a 
hierarchy: At a bottom layer is a USSD service provider 1103, which is known in 
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the art. Above the USSD service provider 1103 is the ITAP service provider 1105, 
which serves as an interface between the USSD service provider 1103 below and a 
service application 1107 above. As a protocol stack, the ITAP service provider 1105 
is responsible for: 

5 - Encoding and decoding ITAP operations. 

Checking semantics of the communications. For example, 
checking to make sure that the first received operation is the ITAP Bind operation. 

Mapping ITAP onto the bearer being used in the particular 
implementation (e.g., USSD). Mapping may include segmenting an ITAP operation 

10 for transmission in two or more bearer protocol data units. 

The ITAP service provider 1105 may also be solely responsible for an 
ITAP operation called getlmageDescription (described below). 

FIG. 12 illustrates a GSM network in which ITAP is used for providing 
a service to an IMS 1201. In this respect, a number of concepts and requirements 

15 described in GSM specifications and CCITT recommendations are useful for 

understanding the environment in which this illustrated embodiment is applied, and in 
particular, the teachings of GSM 02.90; GSM 09.02; GSM 03.38, Version 4.0.0; 
CCITT Recommendation X.208: Abstract Syntax Notation (ASN.l); CCITT 
Recommendation X.229; and CCITT Recommendation X.219 are particularly 

20 pertinent. Each of these GSM and CCITT documents is hereby incorporated by 
reference herein in its entirety. 

The ITAP application 1203 resides in a mobile service node 1101 that 
includes an ITAP service provider 1105 and a USSD service provider 1103 as shown 
in FIG. 11. ITAP messages are carried through the GSM network 1205 by MAP- 

25 USSD messages, and through the air interface on Layer 3-USSD messages. 

An example of an ITAP service will now be described with respect to 
FIGS. 13a through 13e. The service illustrated here is one in which a user wants to 
retrieve messages that are being stored by a service application 1301. At step 1301, a 
user selects the ITAP services main menu on the IMS 1201. In response, the IMS 

30 1201 issues a Proc USSD request invoke (ITAP operation = Bind invoke) to the SN 
1357 in which reside the USSD service provider 1355 at a bottom layer, an ITAP 
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service provider 1353 at an intermediate layer, and the service application 1351 at a 
highest layer (step 1303). The USSD service provider 1355 receives the Proc USSD 
request invoke, and passes the pertinent ITAP operation information up to the ITAP 
service provider 1353, which in turn passes the pertinent information for this service 
5 up to the service application 1351. For the remainder of this description, the service 
application 1351 will be referenced as the recipient and source of messages received 
from and sent to the IMS 1201. However, it will be recognized that these messages 
pass through both the USSD service provider 1355 and the ITAP Service Provider 
1353. 

10 The service application 1351 passes a response back which the ITAP 

service provider 1353 and the USSD service provider 1355 convert into a USSD 
request invoke (ITAP operation = Bind result) message, which is transmitted back to 
the IMS 1201 (step 1305). In response to receipt of this message, the IMS 1201 
displays a menu on its screen (step 1307). The menu is defined by an image 

15 description that is cached in the IMS 1201. The IMS 1201 includes intelligence that 
permits the user to use the arrow keys on the IMS 1201 to scroll among the 
lternatives in the displayed menu. As the user continues to scroll down, more 
alternatives become visible to the user. 

In this example, the user selects a "Messages" sub-menu by pressing 

20 the "YES" key on the IMS 1201 when this alternative is marked (step 1309). This 
causes the IMS 1201 to transmit a USSD request result (ITAP 
operation =MailboxStatus invoke) message to the service application 1351 (step 1311). 

In response, the service application 1351 causes a USSD request invoke 
(ITAP operation =MailboxStatus result) message to be sent to the IMS 1201 (step 

25 1313). This causes the IMS 1201 to display a new menu 1315 indicating, in this 
example, that there are three voice messages and one fax message that can be 
retrieved. In this example, the user scrolls through these alternatives and selects the 
"Voice" sub-menu by pressing "YES" when this alternative is marked (step 1317). 
This selection causes the IMS 1201 to send a USSD request result (ITAP 

30 operation = Enquiry Mailbox invoke) message to the service application 1351 (step 
1319). The response from the SN 1357 is a USSD request invoke (ITAP 
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operation= Enquiry Mailbox result) message (step 1321). This message includes a 
voice message list that will be stored within the IMS 1201. The voice message list 
includes information regarding how many new and how many old voice messages are 
in the list. The IMS 1201 uses this information to display, in this example, a menu 

5 1323 listing two new voice messages and one old voice message. 

The user can scroll through these alternatives and, in this example, 
selects to list new voice messages by pressing the "YES" key on the IMS 1201 when 
this alternative is marked (step 1325). Because the voice message list has already 
been received and stored within the IMS 1201, the user's selection does not cause any 

10 transaction to take place between the IMS 1201 and the service node 1357. Instead, 
information 1327 about the various new voice messages is displayed on the screen of 
the IMS 1201. The user may locally use the arrow keys to scroll through the list of 
new voice messages (step 1329). 

The user selects to play a voice message by pressing the "YES" key on 

15 the IMS 1201 when information about the requested message is displayed (step 1331). 
This selection causes the IMS 1201 to send a USSD request result (ITAP 
operation =PlayMessage invoke) to the SN 1357 (step 1333). The service application 
1351 in the SN 1357 causes a call to be set up between the SN 1357 and the IMS 
1201 (step 1335). The SN 1351 also sends a USSD request invoke (ITAP 

20 operation = Play Message result) to the IMS 1201 (step 1337). 

The ITAP application running in the IMS 1201 responds by performing 
a local function called "Acceptlncomming Call" (step 1339). This causes the IMS 
1201 to accept the call that was set up by the SN 1357 (step 1341). The user can 
now listen to the selected voice message. The screen may also present information 

25 1343 to confirm that the IMS is playing an audio message. 

It will be recognized that the sequence of events in the above example 
are application-dependent, and may therfore vary accordingly. However, it is useful 
to recognize that by implementing part of the service in the SN 1101 and another part 
in the IMS 1201, much of the communication between the SN 1101 and the IMS 1201 

30 can be reduced to a kind of "short-hand", which makes more efficient use of the 
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band-limited control channel 605. In particular, this solution provides the following 
advantages: 

1. Better response times are achieved because there is service logic 
not only in the service application 1107, but also in the IMS 1201. Local logical 

5 decisions can be mad in the IMS 1201. Local menu-handling is also performed in the 
IMS 1201. Communication with the network service application 1107 is only 
performed when network service data needs to be fetched or stored or when a 
network service function needs to be called. 

Furthermore, ITAP operations may be encoded with Basic 
10 Encoding Rules (BER) or Packed Encoding Rules (PER), which gives a more compact 
coding than the short message service (SMS) 7-bit alphabet. 

2. Because there is service application logic in the IMS 1201, a 
much better user interface can be used for the operator specific services, and the same 
MMI-paradigm as for all other services in the IMS 1201 can be used. For example, 

15 for operator specific services, munu-handling may be performed with the same MMI- 
paradigm as for all other functions in the IMS 1201. Also, if the IMS has a graphical 
user interface, this can be utilized. 

3. It is possible ot call local IMS functions through the local IMS 
service application logic. Such local functions might include translating a number into 

20 a corresponding name, activating a ring sinal, or making an automatic "off-hook". 

4. The ITAP semantic prevents the network timers from expiring. 
This means that the length of life for ITAP services is not limited by the network 
USSD timers. 

5. An ITAP operation can be segmented onto several USSD 

25 operations. 

6. There can be more than one ITAP session, carried by one USSD 
dialogue. This makes it possible to temporarily interrupt a service, execute anoterh 
service, and then resume the first service. 

30 Other features of ITAP are: 
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a) The IMS local service application logic and the MMI can be 
controlled by "cacheable" service application scripts, referred to herein as "Image 
Descriptions". These Image Descriptions are loaded from the network into the IMS 
1201 by means of ITAP operations. The Image Descriptions define the service logic 

5 and the MMI in the IMS 1201. The definition of the MMI is at a logical level, that 
is, the current MMI-paradigm of the IMS 1201 is utilized when the services are 
executed. 

The use of Image Descriptions means that, when the service 
application in the network is updated, a new set of Image Descriptions is loaded into 
10 the IMS 1201. No IMS software updating is necessary. 

b) The Image Descriptions are preferably cached in the IMS 1201, 
that is, they stay in the IMS 1201 when the power is switched off. 

c) When an ITAP session is initiated, either by the IMS 1201 or by 
the network service application 1107, a negotiation is performed between the IMS 

15 1201 and the network service application 1107. This guarantees that the service 
applications in the IMS 1201 and in the network are consistent if the service is 
updated in the network. If Image Descriptions are supported, then a new set of Image 
Descritions can be loaded. 

d) An ITAP session can be initiated when an incoming call at the 
20 IMS 1201 is detected. This makes it possible to implement extended incoming call 

services, such as number to name translation with a network-based address database. 

e) In indication of which type of coding (PER or BER) is being 
used is indicated in the initiating ITAP operation. 

f) The ITAP service application 1107 in the network should always 
25 be the data master. This makes it possible for the operator to dynamically manage the 

service data. Also, it makes it possible for the user to manage service data from a 
type of terminal other than an IMS 1207, such as a normal desk telephone or a PC via 
internet WWW. 

g) ITAP is bearer independent. For example, it is possible to map 
30 ITAP onto other available bearers, such as SMS. It is even possible to use ITAP in 

other telephone networks, where a bearer exists. It is possible to use ITAP in: 
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fixed telephone networks; 
analogue/digital mobile networks; and 
satellite networks. 

h) Even though ITAP is bearer independent, ITAP is optimized for 
5 a si wo bearer, such as USSD. 

i) If the bearer supports parallel dialogues, then true parallel ITAP 
sessions can be executed. 

. j) ITAP can be implemented in: 

The mobile equipment part of an IMS; 
10 - At the Subscription Identification Module (SIM) if the 

SIM application toolkit is supported; and 

A PC, a laptop, a communicator, an organizer or any 
computer device connected to a mobile station when there is an interface between the 
mobile station and the computer device that supports USSD and control of call 
15 handling and other mobile station-specific functions. 

As mentioned earlier, one aspect of the invention is the fact that it may 
be optimized for a slow bearer (such as USSD or SMS). In order to obtain 
reasonable response times for the IMS user, the number and size of the operations 
sent between the SN and the IMS is limited. This is achieved by having as much as 
20 possible of the service application logic in the IMS 1201. This is depicted in FIG. 
14. An IMS 1401 includes functions that are partitioned into three layers. From 
bottom to top, these are: an ITAP bearer service provider 1403, an ITAP service 
provider 1405, and service application under ITAP control. 

A SN 1409 also includes functions that are partitioned into three layers. 
25 From top to bottom, these are: an ITAP bearer service provider 1411, an ITAP 
service provider 1413, and one or more service applications 1415. 

In the SN 149 and in the IMS 1401, service application processes 1407, 
1415 are running. Each of these service application processes 1407, 1415 has its own 
state machine, that is, it is not aware of the state in the other unit (IMS 1401 or SN 
30 1409). 
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The service application processes in the SN 1409 and the IMS 1401 
communicate through a set of ITAP operations. Basic ITAP operations include Bind 
1417, Unbind 1419 and Alert 1421. In addition there are, for each service application 
using ITAP, a set of application dependent operations 1423. Each one of these 
5 operations calls a certain SN service application function 1415. 

Note that multiple ITAP sessions could be in progress simultaneously. 
However, whether multiple sessions could be executed in parallel or not depends on 
the bearer capability. For example, as the current version of USSD does not support 
parallel USSD dialogues, a new ITAP session temporarily interrupts an ITAP session 
10 that is already in progress. 

Referring now to FIG. 15, another feature with ITAP is that it is 
possible to change and add services without re-programming the IMS 1401. This is 
achieved by controlling the service application 1407 in the IMS 1401 by means of 
loadable ITAP image descriptions 1501. These image descriptions 1501 define the 
15 MMI, MMI state transitions, local functions to call and SN functions to call. If an 
image description 1501 is missing or not up to date, it may be fetched from the SN 
1409 by means of an ITAP operation called GetlmageDescr 1503. 

Any particular embodiment of ITAP may or may not support image 
descriptions 1501. The following table compares an ITAP architecture with and 
20 without support for image descriptions 1501: 
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No support for image 
descriptions 


Support for image 
descriptions 


Application in IMS 


Hard coded* can not he 
changed without 
reprogramming the IMS. 


l^yiiaiuicdiiy up u a tea 
through loading of 
image descriptions from 
SN. 


IMS functions 


Onlv those fnnrtinriQ 

necessary for the actual 
application needed. 


oLanaaraizect set 01 
functions, accessible 
through the image 
descriptions 


SN functions 


Application dependant 


Application dependant 



A preferred set of ITAP operations will now be described in greater 
detail. The ITAP operations are preferably divided into two main groups: 

Basic ITAP operations: All of these operations are basic, 
service independent, operations and are common for all 
applications using ITAP. 

Application-dependent ITAP operations: These operations are 
invoked by the IMS in order to remotely call a service 
application function in the SN. 
The structure of the operations follow the Remote Operation Service 
Element (ROSE) standard, according to the CCITT Recommendations X.229 and 
X.219, which have been incorporated herein by reference. 

A preferred set of Basic ITAP operations will now be described in 

greater detail. 
Bind 

The Bind operation is invoked by the IMS 1401. It is a ROSE class 1 
operation, that is, it is a synchronous operation and reports success (result) or failure 
(error). Bind is used in either of two situations: 1) to initiate an ITAP service 
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application; and 2) to initiate an ITAP session. These situations are described in 
greater detail below. 

Unbind 

5 The Unbind operation is invoked by the IMS 1401. Itis a ROSE class 

5 operation, that is, the outcome of this operation is not reported. The purpose of 
Unbind is to terminate an ITAP session. 

Getlmape Descr 

10 The GetlmageDescr operation is invoked by the IMS 1401. It is a 

ROSE class 1 operation,that is, it is a synchronous operation and reports success 
(result) or failure (error). The GetlmageDescr operation requests an image 
description from the SN 1409. This operation is invoked by the IMS 1401 when it 
needs to display an image and the corresponding image description does not exist in 

15 the cache. This operatino is only used if the IMS 1401 and the SN 1409 support 
image descriptions. 

Alert 

The Alert operation is invoked by the SN 1409. It is a ROSE class 3 
20 operation, that is, it reports failure (error) only. The purpose of the Alert operation is 
to alert the IMS 1401 about the existence of an event, such as a new messge 
notification. This operation has o response on the ITAP level, but the IMS 1401 
continues the dialogue by invoking Bind, GetlmageDescr, Unbind or an application 
dependent ITAP operation. The Bind operation is invoked if the IMS 1401 has an 
25 application version that differs from that indicated in the Alert operation. 

Regarding application-dependent ITAP operations, these should all be 
ROSE class 1 operations, that is, synchronous and reporting success (result) or failure 
(error). These operations are used when the IMS 1401 requests that a service 
30 application function be executed in the SN 1409. The response from the requested 
function is received as a result of the invoked operation. For each service application 
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1415 that has to use ITAP, a set of application dependent ITAP operations have to be 
specified. There are restrictions on how these operations may be specified. These 
restrictions are described below. 

If image descriptions are supported, then operation codes, invoke 
5 arguments and result arguments for each application dependent operation are specified 
in the image descriptions. 

Initiation of an ITAP service application 
Before a subscriber can access the services of a specific ITAP 
10 application, the ITAP application has to be initiated in the IMS 1409. The procedure 
for this is: 

1. The user enters a menu for initiating an ITAP application at the 
IMS 1401. Then the service code for this application is entered by the user. 

* 2. A Bind operation 1417 is sent from the IMS 1401 to the SN 
15 1409. In this operation "Bind reason" is set to "init subscription". 

3. The SN 1409 returns "Bind result" which contains the name of 
application and information regarding whether Bind should be invoked at an incoming 
call / call waiting indication or not. 

4. The IMS 1401 stores the application parameters. Preferably, the 
20 name of the application should be used in the IMS MMI as the name for the main 

menu for this service application. 

5. The IMS terminates the ITAP session. 

Initiation of ITAP session 
An ITAP session starts with: 

Bind operation 1417, initiated by the IMS 1401. 

or 

Alert operation 1421, initiated by the SN 1409. 
Events that initiate an ITAP session are: 

A user initiates an ITAP service application at the IMS 1401. 

Bind will be sent. 



25 



30 
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An event in the SN 1409. Alert will be sent. 

An incoming call or call waiting indication in the IMS 1401. 

Bind will be sent. 

Because it is necessary to inform the SN 1409 about the reason for 
5. Bind, this operation contains a "Bind reason" parameter. The "Bind reason" has the 
following values: 

User initiated. 

Call related indications, that is, incoming call and call waiting. 
Incorrect application version. This is used when the SN 1409 
10 initiates an ITAP session with Alert and the IMS 1401 discovers that the application 
version is different from the version in the SN 1409. 

Initiate subscription, as described above with respect to Initiation 
of an ITAP service application . 

When the SN 1409 receives the Bind operation, it compares the 
15 application version in the IMS 1401 with the application version in the SN 1409. If 
the SN 1409 has an application version that differs from that which is currently 
supported by the IMS 1401, then: 

If image descriptions are not supported, the SN 1409 changes to 
the application version that is supported by the IMS 1401. If the SN 1409 does not 
20 support that application version, Bind error is returned and the ITAP session is 
terminated. 

If image descriptions are supported, then the Bind response 
contains a list of image descriptions to clear from the cache. 

The Bind result operation also includes a parameter which specifies 
25 which sub-services this subscriber may use. The IMS 1401 checks this parameter 
when a menu should be presented. If a menu contains an option for a service that is 
not included in the subscription, this option will not be displayed. This makes it 
possible for an operator to split a service application into a number of sub-services. 
A subscriber can then decide which subservices he/she wants to use. 



30 



Termination of an ITAP session 

An ITAP session is normally terminated by an Unbind operation, 
initiated by the IMS 1401. However, in error cases the ITAP session could be aborted 
by an abort at bearer level both by the IMS 1401 and the SN 1409. 

5 

ITAP timeout handling 

Timeouts are handled by both the SN 1409 and by the IMS 1401. 

Regarding timeout handling by the SN 1409, there should be an "idle" 
timer in the SN 1409. This timer is always started when an operation (Alert or ROSE 
10 class 1 operation Result, Error or Reject) has been sent to the IMS 1401. The initial 
value of the SN "idle" timer is constant. 

Time-out is detected when no new operation (Bind, GetlmageDescr, 
Unbind or an application dependent ITAP operation) is invoked by the IMS 1401 
within the specified time period. When time-out is detected, the SN 1409 should 
15 locally abort the ITAP session and, if the bearer has a dialogue structure, abort the 
dialogue on the bearer level. 

Regarding timeout handling by the IMS 1401, the IMS 1401 should 
have a timer which supervises the response to a ROSE class 1 operation invoked by 
the IMS 1401 (Bind, GetlmageDescr or an application-dependent ITAP operation). A 
20 timer value should be specified for each operation sent. For application-dependent 
ITAP operations the timer value depends on the operation invoked. If image 
descriptions are supported, the timer value, for application-dependent ITAP 
operations, is specified in the image description. 

Time-out is detected when no response (Result, Error or Reject) is 
25 received from the SN 1409 within the specified time period. When time-out is 

detected, the IMS 1401 should locally abort the ITAP session and, if the bearer has a 
dialogue structure, abort the dialogue on bearer level. 

In addition, the IMS 1401 should have an "idle" timer which monitors 
whether the user performs an action within a specified time period. This timer is 
30 always started when an operation (Alert or ROSE class 1 operation Result, Error or 
Reject) has been received from the SN 1409. The initial value of the "idle" timer is 
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constant, except for the situation when Alert has been received. In this case the timer 
value is specified with a parameter in the Alert operation. 

When the IMS 1401 detects "idle time-out", the IMS 1401 should make 
a normal ITAP termination by sending an Unbind to the SN 1409. 

5 

ITAP error handling 

Error handling at the ITAP level is performed according to ROSE. If 
an error or time-out occurs at the bearer level, all ITAP sessions carried by this 
bearer dialogue should be aborted. 

10 

Coding of ITAP operations 

Operations are coded according to Basic Encoding Rules (BER) or 
Packed Encoding Rules (PER). However, PER is preferred because this coding 
standard gives shorter operations and better performance for the IMS user. 

15 

Maximum size of ITAP operations 

In a preferred embodiment, the maximum size of an ITAP operations 
should be limited to 1024 octets. This limitation will also define the maximum size of 
an ITAP image description. The size of an ITAP image description together with the 
20 ROSE header should not exceed 1024 octets. 



The discussion will now focus on ITAP image descriptions. ITAP 
image descriptions are resources that define: 

The MMI at the IMS 1401 when the service is executed. In the 
25 image descriptions, the MMI definition is made on a rather high logical level. The 
actual image formatting and presentation is decided by the IMS 1401. 

Call of functions in the IMS 1401 and the SN 1409 when the 

service is executed. 

An image description specifies objects from the following list: 
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Lists of action items that consist of local IMS function calls, 
invocation of application-dependent ITAP operations ("SN function calls"), conditional 
statements and label statements. 

Fixed text. 

5 - Actions related to IMS standard keys. 

Menus with an action for each menu option. 
Lists of dynamic data. 
Different types of input/output fields. 
Terminal registers for temporary storage of dynamic data. 
10 An exemplary image description 1601 for a menu of options is depicted 

in FIG. 16. From the image description 1601, it is possible to call local IMS 
functions 1603 and remote SN functions 1605. When a function is called, the input 
and output parameters are stored in temporary registers. These registers are referred 
to in input/output fields, lists, and the like. The remote SN functions are called 
15 through the set of application dependent ITAP operations 1605 that is available for the 
current application. 

For local IMS functions, ITAP specifies a set of functions to be 
supported by the IMS. The IMS functions are divided into the following groups: 
Functions for manipulating image description objects, such as 
20 image descriptions, registers and parameter lists. 

Call related functions, such as "Accept incoming call" and "Set 



up call". 



25 telephone book, 
tone generator. 



Functions for handling DTMF signals. 

Functions for accessing local IMS software objects, such as the 
Functions for accessing local IMS hardware objects, such as the 



Functions for handling SMS. 
A list of local IMS functions, with input and output parameters, is 
30 described later in this description. 
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In order to support ITAP, the SN 1409 and the IMS 1401 should each 
satisfy a number of requirements, as follows: 

REQUIREMENTS ON THE SN 1409 

The SN 1409 should support the bearer protocol that has been 

5 selected for ITAP. 

The SN 1409 should support the basic operations of the ITAP 
protocol and be able to code/decode the ITAP-data types according to PER or BER. 

The SN 1409 should, for each ITAP application implemented, 
support a set of application dependent ITAP operations. 
10 - The SN 1409 should, for each subscriber, remember the selected 

language, in order to produce correct text strings in operation arguments. 

Additionally, the following SN requirements should be satisfied when 
image descriptions are supported: 

The SN 1409 should be able to store image descriptions and, on 
15 request from the IMS 1401, load them into the IMS 1401. 

The SN 1409 should keep track of which image descriptions 
have to be replaced in the IMS 1401 when a new version of an ITAP application is 
introduced. 

20 REQUIREMENTS ON THE IMS 1401 

The IMS 1401 should support the bearer protocol that has been 

selected for ITAP. 

The IMS 1401 should support the basic operations of ITAP 
protocol and be able to code/decode the ITAP-data types according to PER or BER. 
25 - The IMS 1401 should, for each ITAP application implemented, 

support a set of application dependent ITAP operations. 

The IMS 1401 should be able to leave the normal mode of 
operation and transition to a mode where the user application mainly is controlled by 
an ITAP application part. The ITAP mode is initiated by a user command, by a call 
30 indication or via a received ITAP alert. 
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A set of basic IMS functions for call control, MMI-control, 
SMS control and the like should be accessible from the ITAP part of the IMS 1401. 

The ITAP software should be able to use existing software 
objects in the IMS, such as the telephone book. 

Additionally, the following IMS requirements should be satisfied when 
image descriptions are supported: 

Memory for dynamic storing of image descriptions and 
temporary data should be available in the IMS 1401. Image descriptions should stay 
resident in memory when the power has been switched off. The memory size 
required for storing image descriptions depends on the number of images used for the 
services and the complexity of the services. It is estimated that in most cases, an 
image description will not be bigger than 200 bytes. So, if a complex ITAP 
application needs 60 image descriptions, then 12 Kbytes must be allocated in the IMS 
1401 for image descriptions. 

The IMS 1401 should be able to interpret image descriptions and 
control the ITAP application and the set of application dependent ITAP operations 
through the image descriptions. 

System Operator management should also support ITAP. One feature 
with the ITAP concept is that dynamic loading of image descriptions is possible. The 
scenario when an operator updates a service is: 

1. The new service application version is installed in the SN 1409. 

2. When contact is established the first time after the version has 
been updated in the SN 1409, the SN 1409 detects that the IMS 1401 has an old 
version. 

3. The SN 1409 orders the IMS 1401 to clear the image description 
cache or a part of the cache. 

4. When the services are executed, the IMS 1401 uses the 
"GetlmageDescr" operation to request the missing image descriptions when they are 
needed during the execution of the services. 

If image descriptions are supported, then the ITAP concept places the 
following requirements on the operator: 
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SN service application logic modifications and image description 
updates must be coordinated. 

A management tool for creating and managing image 
descriptions has to be created. 

5 

A technique for mapping ITAP operations on the parameter "USSD 
string" in the USSD operations according to GSM phase 2 will now be described with 
respect to FIGS. 17 and 18. FIG. 17 illustrates a mapping that would be used for a 
USSD operation that initiates a USSD dialogue. FIG. 18 illustrates a mapping that 
10 would be used for all other operations. Each string has a USSD specific header 1701, 
1801 and a bearer independent part 1703, 1803. The following text explains the 
different fields of the USSD strings: 

ITAP Service Code 1705: 
15 This field is necessary only in operations that initiate a USSD dialogue. 

The purpose of this field is: 

Routing information for MS initiated USSD dialogue: Informs 
the serving network that the USSD operation should be routed to the HLR of the 
HPLMN of the subscriber. The specification for GSM 02.90, section 4.1.2, case a), 
20 states the required format for an MS initiated USSD operation when it is to be routed 
to the HLR of the HPLMN. 

The service code also informs the HLR that the USSD operation 
should be routed to the correct external node (SN). 

Protocol identifier for network initiated USSD dialogue: 
25 Identifies, for the IMS 1401, that a received initiating USSD operation contains an 
ITAP operation instead of a standard USSD string. 

Application identity: Specifies the identity of the application, 
using ITAP, that is started. 
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ITAP Version Number 1707: 

This field, which specifies the ITAP version number, is found only in 
initiating USSD operations. 

5 Coding 1709 (only initiating USSD operations): 

This field, which is found only in initiating USSD operations, specifies 
the coding rules used for encoding the ITAP operations. An exemplary encoding is as 
follows: 

0 = Basic Encoding Rules 
10 1 = Packed Encoding Rules, basic aligned. 

2 = Packed Encoding Rules, basic unaligned. 

3 = Packed Encoding Rules, canonical aligned. 

4 = Packed Encoding Rules, canonical unaligned. 

15 Session Id 1711 (all operations): 

This field, which designates the ITAP session identity, is found in all 

operations. 

Seg Flag 1713 (all operations): 
20 This field, which designates segmentation information, is found in all 

operations. It is used for long ITAP operations that do not fit into the USSD string of 
one USSD operation. The values of this flag are: 

0 = "no more info". This USSD operation contains the complete 
ITAP operation or this USSD operation contains the last part of the ITAP operation 

25 that is being sent. 

1 = "more to come". This USSD operation does not contain the 
complete ITAP operation or this is not the last part of the ITAP operation that is 
being sent. 

2 = "get more info". When an entity (IMS 1401 or SN 1409) receives 
30 a USSD operation with seg flag 1713 set to "more to come", it replies with a USSD 

operation having seg flag 1713 set to "get more info". In this case, the field "ITAP 



operation" 1719, 1819 is empty, and only the USSD specific header 1701, 1801 is 
included in the USSD string. 

It is preferred that PER or BER encoding of an ITAP operation be 
performed before a possible segmentation is performed. Decoding of a received 
5 ITAP operation should not be performed until the complete operation has been 
received. 

Operation scenario diagrams are presented later which describe the 

segmentation. 

10 USSD dialogue flag 1715 (all operations): 

The purpose of this flag is to solve problems with USSD timeouts in 
the network. If this flag is set to 0, then the USSD string contains a normal ITAP 
operation. In all other cases the field "ITAP operation" 1719, 1819 is empty. 

Values 1 and 2 are used in dummy USSD operations that are sent in 

15 order to prevent the USSDRequest invoke timer in the network from expiring. Each 
time control is returned to the IMS 1401, that is, an ITAP result or ITAP Alert 
invoke carried by a USSDRequest invoke is received, a timer in the IMS 1401 is 
started. The value of this IMS timer should be less than the value of the 
USSDRequest invoke timer in the network. When an ITAP operation, carried by the 

20 USSDRequest result, is sent, the IMS timer is cancelled. If the IMS timer expires, a 
"dummy request" (USSD dialogue flag = 1), carried by USSDRequest result, is sent. 
The SN 1409 replies with "dummy confirm" (USSD dialogue flag = 2), carried by 
USSDRequest invoke. 

Values 3 - 5 are used in USSD operations that are sent in order to 

25 avoid, for the case of IMS initiated USSD dialogues, expiration of the 

ProcessUSSDRequest invoke timer in the network. These USSD operations are used 
to terminate the IMS-initiated USSD dialogue and initiate a new, network initiated, 
USSD dialogue. The ITAP session in progress continues, carried by this new USSD 
dialogue. The procedure for this is as follows: 

30 Always when the IMS 1401 initiates a USSD dialogue with 

ProcessUSSDRequest invoke, the IMS 1401 starts a timer. The value of this IMS 
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timer must be less than the value of the ProcessUSSDRequest invoke timer in the 
network. As the "switch USSD dialogue" procedure could only be initiated by the 
IMS 1401, the maximum time control which could be in the SN 1409 must also be 
considered when this IMS timer is specified. If this IMS timer expires, a "switch 
5 USSD dialogue request" (USSD dialogue flag = 3), carried by USSDRequest result, 
is sent. The SN 1409 replies with "switch USSD dialogue confirm" (USSD dialogue 
flag = 4), carried by ProcessUSSDRequest result in a TCAP-END message. This 
mobile initiated USSD dialogue has now been terminated and a new, network initiated 
USSD dialogue should be set up by the SN 1409. The initiating USSDRequest invoke 
10 contains a "resume ITAP session" command (USSD dialogue flag = 5). Now the 
ITAP session continues, carried by this new, network initiated, USSD dialogue. 

ITAP operation scenarios are presented below for Handling in order to 
avoid USSD timeout in the network. 

An explanation of the problems with the USSD operation and idle 
15 timers in the network is presented below. 

The value 5, "resume ITAP session", of the USSD dialogue flag 1715 
is also used when a previously interrupted ITAP session is to be resumed on the same 
USSD dialogue. An example of this scenario is presented below. 

20 USSD specific tail 1717: 

This specific tail 1717, which is included only in initiating USSD 
operations, has to be added according to GSM 02.90, section 4.1.2, case a. The "#" 
character requires 7 bits in the SMS default alphabet. The eighth bit should be set to 
0. 

25 

Turning now to the bearer independent part, the USSD string would 

include: 



30 



ITAP Operation 1719. 1819: 

This filed is used in all operations, except when seg flag = "get more 
info" or when USSD dialogue flag < > "normal ITAP operation"). The ITAP 
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operation follows the ROSE structure, as described in CCITT Recommendations 
X.229 and X.219, and is coded according to the rules of PER or BER. 

The maximum length of the ITAP operation is at this stage rather 
unclear, as the max length of an USSD string is not very clearly specified in the GSM 
5 specifications: 

For a USSD Request invoke or Process USSD Request invoke: 
GSM 09.02 states a maximum length of 160 octets. However, there are also 
limitations in the TCAP-layer. Different USSD experts have given different 
information about how these limitations impact the length of an USSD string. Figures 
10 between 100 and 150 octets have been mentioned. In addition, it has also been 
mentioned that if the USSD string is longer than 128 octets it will be segmented on 
the A-interface, which will increase response times. 

For an USSD Request result or Process USSD Request result : 
GSM 02.90 states that result USSD strings are limited to a maximum of 80 
15 characters, coded according to the 7-bit default alphabet. This means that the 
limitation is 70 octets. However, it has been suggested in SMG to remove this 
limitation in GSM 02.90. 

Because the maximum length of a USSD string is so unclear, and also a 
matter of change proposals, it is preferable to have the USSD string max lengths for 
20 the different USSD operations as configuration parameters in the SN 1409 and 
possibly also in the IMS 1401. 

The following table shows how the ITAP operations are mapped on the 
USSD operations: 



25 
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ITAP OPERA TION 


MAPPED ON USSD OPERATION 


Invoke (Bind) 


Invoke (Process USSD Request) when an ITAP session 
is initiated by the IMS 1401 and no earlier ITAP 
session is in progress. 

Result (USSD request) when the SN 1409 has initiated 
an ITAP session with Alert or when another ITAP 
session already is in progress. 


Result, Error or Reject 
(Bind) 


invoke (UobU Request) 


Invoke (Unbind) 


Result (USSD Request) 


Reject (Unbind) 


Invoke (USSD Request) 


Invoke ("application 
dependent ITAP 
operation") 


Result (USSD Request) 


Result, Error or Reject 
("application dependent 
ITAP operation ") 


Invoke (USSD Request) 


Invoke (GetlmageDescr) 


Result (USSD Request) 


Kesuit, error or Kejeci 
(GetlmageDescr) 


mvoKC ^ujjL' xvcqucdL^ 


Invoke (Alert) 


Invoke (USSD Request) 


Error or Reject (Alert) 


Result (USSD Request) 



20 The DCS (Data Coding Scheme) is a parameter in the USSD operation 

that contains language, alphabet and message class information. GSM 02.90 specifies 
how the alphabet indicator and the language indicator should be set: 

For mobile initiated USSD operation: Alphabet indicator = "SMS 
default alphabet", Language indicator = "Language unspecified". The response is not 

25 specified. 
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For network initiated USSD operation: Request not specified but 
response DCS should be set to "SMS default alphabet" and "Language unspecified". 

According to GSM 02.90, it seems that operations sent from the IMS 
5 1401 should have the alphabet indicator = "SMS default alphabet" and the language 
indicator = "Language unspecified". Operations sent from the SN 1409 could, 
according to GSM 02.90, use other values for these indicators. However, at the 
current stage it is uncertain whether HLR and MSC/VLR in CME20, R6.1 
(equipment supplied by Telefonaktiebolaget LM Ericsson, the assignee of the present 
10 invention), will accept an alphabet indicator other than "SMS default alphabet." 

As a conclusion, the main alternative, due to possible CME20 
limitations, is to set the alphabet indicator to "SMS default alphabet" and the language 
indicator to "Language unspecified" for all operations. According to GSM 03.38, this 
means that the DCS should have the binary value "00001111". 

15 

The following sections describe problems and solutions associated with 
USSD operations and idle timers in the network: 

General 

20 When a service which uses ITAP for communication between a SN 

1409 and an IMS 1401 is executed it is necessary to have an ITAP session active 
during the execution of the service. 

There are timers in the network nodes, HLR and MSC, which abort the 
USSD dialogue if an invoked USSD operation is not replied to within a certain time 

25 period or if the USSD dialogue is idle for a certain time period. The timer values are 
in the range of 30 sec to 10 minutes. As a consequence of this, the length of services 
using ITAP is limited. This is a problem because it is desirable to be able to keep the 
ITAP session for a long time for advanced services. It is likely that there will be 
situations when the user keeps an ITAP session for more than 10 minutes. 

30 
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Problem with the ProcessUSSDRequest timer 
Description: This timer has a value of 1-10 minutes and is started 
when ProcessUSSDRequest invoke is received in the SN 1409. The timer runs during 
the whole USSD dialogue until ProcessUSSDRequest result is received from the SN 
5 1409. 

Consequences for ITAP: This timer limits the total length of all 
mobile-initiated USSD dialogues and as a consequence, the length of all ITAP 
sessions initiated by the user of the IMS 1401 is limited. 

Solution: The IMS 1401 has a timer which is started when an IMS- 
10 initiated ITAP session is initiated with "Bind invoke" mapped on 

ProcessUSSDRequest invoke. This timer value must be shorter than the 
ProcessUSSDRequest invoke time-out value in the network. When the IMS timer 
expires, a switch to a network initiated USSD dialogue is performed. The ITAP 
session continues and is mapped on this new USSD dialogue. 

15 

Problem with the USSDRequest timer: 

Description: This timer has a value of 1-10 minutes and is started 
when USSDRequest invoke is sent. The timer runs until USSDRequest result is 
received from the IMS 1401. 
20 Consequences for ITAP: This timer limits the ITAP idle time in the 

IMS 1401, that is, the length of time the IMS 1401 can wait until the next ITAP 
operation is sent. 

Solution: If the IMS 1401 has not invoked an ITAP operation within a 
certain time (slightly shorter than the USSDRequest invoke timer), then a dummy 
25 USSDRequest result is sent. The SN 1409 replies with a dummy USSDRequest 
invoke. 

Problem with the USSD idle timer in HLR: 

Description: This HLR timer has a value of 30 seconds to 5 minutes 
30 and supervises the time between invocations of USSD operations. The timer is started 
when USSDRequest result has been sent to the SN 1409 and runs until the next 
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USSDRequest invoke is received from the SN 1409 or until the USSD dialogue is 
closed. 

Consequences for ITAP: This timer limits the time an ITAP operation 
invoke can be outstanding in the SN 1409 before a reply is sent. 
5 Solution: The SN 1409 must always reply to an invoked ITAP 

operation before the USSD idle timer expires. 

The use of USSD as a bearer imposes some limitations on ITAP 
functionality. The following limitations are valid for USSD according to the GSM 

10 phase 2 specifications: 

Only one ITAP session at a time can be active because multiple 
USSD dialogues with an IMS 1401 are not possible. If a new ITAP session is started 
when there already is a session active, the first session is. temporarily interrupted. 
When the second ITAP session is terminated, the first session is resumed. 

15 - If there is an ITAP session in progress and a new session has to 

be started, the new session can only be initiated by the IMS 1401, with the Bind 
operation. It is in this case not possible to start a new session from the SN 1409 with 
Alert. The reason is that ITAP operations are invoked by the IMS 1401, except for 
Alert, and the SN 1409 replies with result. The result operation from the SN 1409 is 

20 mapped onto "Invoke (USSD request)". If an Alert were sent, then a parallel "Invoke 
(USSD request)" would have to be sent. However, multiple invocations are not 
allowed in USSD. . 

If an ITAP session is initiated by the SN 1409 with an Alert and 
no reply is received from the IMS 1401 within a specified time-period, then the 

25 initiated session is aborted in the SN 1409. However, it is not possible to abort the 
USSD dialogue in the network and IMS 1401, because this is the first USSD 
operation in this dialogue. If the application timeout in the SN 1409 is shorter than 
the MSC/VLR USSD timeout, the USSD channel towards the IMS 1401 will be 
blocked until the MSC/VLR timeout expires (because MSC/VLR allows only one 

30 USSD dialogue at a time). 
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USSDRequest invoke is received from the SN 1409 or until the USSD dialogue is 
closed. 

Consequences for ITAP: This timer limits the time an ITAP operation 
invoke can be outstanding in the SN 1409 before a reply is sent. 
5 Solution: The SN 1409 must always reply to an invoked ITAP 

operation before the USSD idle timer expires. 

The use of USSD as a bearer imposes some limitations on ITAP 
functionality. The following limitations are valid for USSD according to the GSM 

10 phase 2 specifications: 

Only one ITAP session at a time can be active because multiple 
USSD dialogues with an IMS 1401 are not possible. If a new ITAP session is started 
When there already is a session active, the first session is temporarily interrupted. 
When the second ITAP session is terminated, the first session is resumed. 

15 - If there is an ITAP session in progress and a new session has to 

be started, the new session can only be initiated by the IMS 1401 , with the Bind 
operation. It is in this case not possible to start a new session from the SN 1409 with 
Alert. The reason is that ITAP operations are invoked by the IMS 1401, except for 
Alert, and the SN 1409 replies with result. The result operation from the SN 1409 is 

20 mapped onto "Invoke (USSD request)". If an Alert were sent, then a parallel "Invoke 
(USSD request)" would have to be sent. However, multiple invocations are not 
allowed in USSD. 

If an ITAP session is initiated by the SN 1409 with an Alert and 
no reply is received from the IMS 1401 within a specified time-period, then the 

25 initiated session is aborted in the SN 1409. However, it is not possible to abort the 
USSD dialogue in the network and IMS 1401, because this is the first USSD 
operation in this dialogue. If the application timeout in the SN 1409 is shorter than 
the MSC/VLR USSD timeout, the USSD channel towards the IMS 1401 will be 
blocked until the MSC/VLR timeout expires (because MSC/VLR allows only one 

30 USSD dialogue at a time). 
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It should be noted that if the timeout is caused by "no input from user", 
then this problem is solved by the "idle" timer in the IMS 1401 as described above, 
and illustrated below. 

FIGS. 19-51 illustrate ITAP operation scenarios utilizing USSD 
5 (according to GSM phase 2) as a bearer. 

FIG. 19 illustrates a Bind operation when no existing ITAP session is 
in progress. Here, the IMS 1401 initiates the ITAP session, with the IMS application 
version being up to date (i.e. , the version level in the terminal matches the version 
level in the service node). 
10 FIG. 20 illustrates another Bind operation when no existing ITAP 

session is in progress. Here, however, the IMS 1401 initiates the ITAP session, with 
the IMS application needing to be updated. It is assumed that image descriptions are 
supported. It can be seen that at time =2, the SN 1409 sends a Result that includes a 
new application version, instructions to clear the cache in the IMS 1401, and a list of 
15 images to clear. 

FIG. 21 illustrates an ITAP scenario in which the IMS 1401 initiates an 
ITAP session by means of a call-related indication 2101 at a time when no ITAP 
session is in progress. 

FIG. 22 illustrates an ITAP scenario in which the IMS 1401 initiates an 
20 ITAP session using the Bind operation, and in which the SN detects an error or 

rejects the Bind operation. Note that at time=3, it is also possible that the IMS 1401 
retries the Bind operation with a "Continue, Result (USSD req)". 

FIG. 23 illustrates an ITAP scenario in which the IMS 1401 initiates an 
ITAP session at a time when an existing IMS session is already in progress. Note 
25 that if an event (e.g., a call indication), which triggers a new session, is detected and 
the session in progress has an outstanding invoke operation, then the operation reult 
must be received before a Bind for the new session can be invoked. 

FIG. 24 illustrates an ITAP scenario in which the IMS 1401 initiates an 
ITAP session at a time when an existing IMS session is already in progress, and in 
30 which the SN 1409 detects an error or rejects the Bind operation (step 2401). Note 
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that at time =4, it is also possible for the IMS 1401 to retry sending the Bind 
operation for session 2. 

FIG. 25 illustrates the initiation of an ITAP service at a time when no 
application data is available in the IMS 1409. Note that when the IMS 1401 receives 
5 the bind result (step 2501), the application parameters are stored in the IMS 1401. 
The ITAP session is always terminated after the ITAP service is initiated. 

FIGS. 26 and 27 illustrate application-dependent ITAP operations. In 
FIG. 26, a successful response is received from the SN 1409 (step 2601). In FIG. 
27, the SN 1409 detects an error or rejects the operation 2701. 
10 FIGS. 28 and 29 illustrate the GetlmageDescr operation. In FIG. 28, a 

successful response is generated by the SN 1409 (step 2801). In FIG. 29, the SN 
1409 detects an error or rejects the oepration (step 2901). 

FIGS. 30, 31 and 32 illustrate a number of ITAP scenarios involving 
the Unbind operation. In FIG. 30, only one session is in progress, and a successful 
15 response is generated by the SN 1409 (step 3001). Note that at time-3, the USSD 
dialogue is closed with an empty TCAP-rEnd if the USSD dialogue was initiated by 
the SN 1409. If the USSD dialogue was initiated by the IMS 1401, then the USSD 
dialogue is closed with Result (Process USSD req). 

In FIG. 31, a prevously interrupted session is to be resumed, and a 
20 successful response is generated by the SN 1409 (step 3101). 

FIG. 32 illustrates a scenario in which one or several sessions are in 
progress, and in which the SN 1409 rejects the Unbind (step 3201). Note that all 
ITAP sessinos will be aborted in this situation. This is necessary because the attempt 
to erminate a session on the ITAP level failed and a deadlock situation needs to be 
25 avoided. 

FIGS. 33 through 39 illustrate a number of scenarios involving the 
Alert operation. FIG. 33 shows a situation in which the SN 1409 alerts the IMS 1401 
about an event (step 3301) and the IMS application version is up to date. 

In FIG. 34, the SN 1409 alerts the IMS 1401 about an event when the 
30 IMS application version is not equal to the one in the SN 1409. The illustrated 
scenario is for the case in which image descriptions are supported. 
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FIG. 35 illustrates a scenario in which the SN 1409 alerts the IMS 1401 
about an event (step 3501) at a time when the IMS application version is not equal to 
the version in the SN 1409. In this case, the IMS 1401 does not support image 
descriptions, and the SN 1409 is backward compatible. 
5 FIG. 36 depicts a scenario in which the SN 1409 alerts the IMS 1401 

about an event (step 3601). In this case, the IMS 1401 supports an older version of 
ITAP, and the SN 1409 is backward compatible. 

In FIG. 37, the SN 1409 alerts the IMS 1401 about an event (step 
3701). Here, the IMS 1401 supports an older version of ITAP, but the SN 1409 is 
10 not backward compatible. As a result, the SN 1409 closes the USSD dialogue (step 
3703). 

In FIG. 38, the SN 1409 generates an Alert operation (step 3801), but 
the IMS 1401 detects an error or rejects the Alert operation (step 3803). 

In FIG. 39, the SN 1409 detects an error or rejects the Bind operation 

15 that follows an Alert (step 3901). 

FIG. 40 depicts an ITAP scenario in which the IMS 1401 rejects a 
response from the SN 1409. That is, at step 4001, the SN 1409 sends a Result, Error 
or Reject to the IMS 1401. At step 4003, the IMS 1401 is unable to properly 
interpret the reply from the SN 1409, so at step 4005 the IMS 1401 sends an Unbind 

20 operation to the SN 1409. Note that according to CCITT Recommendation X.219, 
section 10.4, it is optional whether a ROSE-user implements rejection of a reply 
(Result or Error Application Protocol Data Unit (APDU) by sending a Reject APDU. 
For the illustrated embodiment of ITAP, it has been selected, for the IMS 1401, not 
to send a Reject APDU in the case of an erroneous Result or Error APDU from the 

25 SN 1409. Instead, the ITAP session is terminated by an Unbind in this situation. 

It has been described, with respect to FIGS. 17 and 18, how ITAP may 
be mapped onto a USSD string. In the following scenarios, depicted in FIGS. 41 
through 43, the segmentation flag 1713 in the USSD specific header 1701, 1801 is 
used for segmentation information. If the PER or BER coded ITAP operation does 

30 not fit into the USSD string of a USSD operation, it has to be split into two or more 
USSD operations. When the IMS 1401 or the SN 1409 has received an operation 
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with the segmentation flag set to "more to come", then a USSD operation with just 
the header, where the segmentation flag is set to "get more info", should be sent to 
the other entity. When the complete ITAP operation has been received, it should be 
decoded by the receiving entity. 
5 Turning now to FIG. 41, an IMS-invoked operation that does not fit 

into one USSD operation is shown. The solution is to split it into two operations 
4101, 4103. 

FIG. 42 illustrates a scenario in which the SN 1409 invokes an ITAP 
operation that does not fit into one USSD operation. The solution is to split the ITAP 
10 operation into two USSD operations 4201, 4203. 

FIG. 43 shows a scenario in which an operation result sent by the SN 
1409 does not fit into one USSD operation. The solution is to split the ITAP 
operation result into two USSD operations 4301, 4303. 

Timeout handling on the ITAP level will now be discussed with 
15 reference to FIGS. 44 through 49. Referring first to FIG. 44, this depicts a scenario 
in which the IMS 1401 detects a timeout (step 4401) after an operation has been 
invoked. In response, all ITAP sessions are aborted, and an End operation is sent to 
the SN 1409 (step 4403). 

FIG. 45 illustrates a scenario in which the IMS 1401 detects a timeout 
20 after a Bind has been invoked as a first operation for this USSD dialogue (step 4501). 
The IMS 1401 responds by locally aborting the ITAP session and the USSD dialogue 
(step 4503). 

In FIG. 46, the IMS 1401 detects an "idle" timeout, that is, no 
response is received from the user (step 4601). The IMS 1401 responds by 
25 generating invoking an Unbind operation (step 4603). As a result, an Unbind 

scenario continues (step 4605), that is, a USSD dialogue is closed or a previously 
interrupted session is resumed. 

FIG. 47 depicts a scenario in which the IMS 1401 detects an "idle" 
timeout, that is, no response from the user, after an Alert has been received (step 
30 4701). In response, the IMS 1401 terminates the ITAP session (step 4703), including 
invoking an Unbind operation (step 4705). 
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In FIG. 48, it is the SN 1409 that detects the "idle timeout" (step 
4801). In response, the SN 1409 aborts all ITAP sessions (step 4803), including 
sending an Abort operation to the IMS 1401. 

FIG. 49 illustrates a scenario in which the SN 1409 sends an Alert (step 
4901), and subsequently detects an "idle" timeout (step 4903). In response, the SN 
1409 performs a local abort of the ITAP session and the USSD dialogue. 

FIGS. 50 and 51 depict scenarios involving handling that may be 
performed in order to avoid a USSD timeout in the network. In FIG. 50, a dummy 
USSD operation (step 5001) is performed in order to avoid a USSDRequest timeout. 
In FIG. 51, expiration of a timer in the IMS 1401 (step 5101) causes a switch to be 
made from an IMS-initiated USSD dialogue to a network-initiated USSD dialogue 
(steps 5103 and 5105) in order to avoid a ProcessUSSDRequest timeout. The switch 
causes the mobile-initiated USSD dialogue to be terminated, and a new, network- 
initiated USSD dialogue to be set up (step 5107). After the switch, the SN 1409 may 
resume the ITAP session (step 5109). " 

The various ITAP operations in accorance with one embodiment of the 
invention will now be described in greater detail. ITAP uses the concept of remote 
operations for specification of interactive communication between the application 
entities. ITAP is specified using ROSE and ASN.l syntax as defined in CCITT 
Recommendation X.208: Abstract Syntax Notation (ASN.l), and CCITT 
Recommendation X.229: Remote Operations: Protocol Specification, which were 
incorporated by reference above. 

REMOTE OPERATION 

The ITAP operations are defined with the four ROSE primitives: 
Invoke (request) 
Result (positive outcome) 
Error (negative outcome) 
Reject (protocol error) 
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Each ITAP operation will be classified according to the rules defined 

by ROSE: 

Operation class 1, synchronous, reporting success or failure; 
Operation class 2, asynchronous, reporting success or failure; 
5 - Operation class 3, asynchronous, reporting failure only; 

Operation class 4, asynchronous, reporting success only; and 
Operation class 5, outcome not reported. 

TIMER 

10 The timer range value that is used complies to the range defined by 

MAP: 

s = from 3 seconds to 10 seconds 
m = from 15 seconds to 30 seconds 
ml = from 1 minute to 10 minutes 
15 1 = from 28 hours to 38 hours 

There are two types of timers: operation and idle timers. The operation 
timer is invoked when the requesting application entity is waiting for the outcome of a 
request. If no outcome is returned before the timer expires, the operation is 
cancelled. The ITAP operation timers are specified for each ITAP operation in the 
20 section below entitled "BASIC ITAP OPERATIONS". 

The idle timer is invoked in the IMS 1401 when there is no outstanding 
request for service and invoked in the SN 1409 when no request is being executed. If 
there is no activity on the session, the idle timer will expire. The idle timer in the 
IMS 1401 and SN 1409 should be: 
25 - MS, ml 

SN, ml 

It should be noted that since the IMS 1401 will send an Unbind 
operation when the idle timer expires in the IMS 1401, the idle timer ought to be a 
little bit shorter in the IMS 1401 than in the SN 1409 so that the session can be 
30 terminated in a proper way. 
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BASIC AND APPLICATION DEPENDENT ITAP OPERATIONS 
The ITAP operations are divided into two main groups: 
Basic ITAP operations: All these operations are basic, service 

independent, operations and are common for all applications using ITAP. These 
5 operations are specified in the following section. 

Application dependent ITAP operations: Operations invoked by the 

IMS 1401 in order to remotely call a service application function in the SN 1409. 

Rules and restrictions for these functions are specified in a section below. 

10 BASIC ITAP OPERATIONS 

The data types that are not specified in this document are specified in 
the sections below that describe Image Descriptions in greater detail. 

GENERAL 

15 If AP-Operations DEFINITIONS IMPLICIT TAGS :: = 
BEGIN 



20 



25 



IMPORTS 



EXPORTS 



OPERATION, ERROR FROM Remote-Operations{joint-iso-ccitt 
remote-operations(4) notation(O)} 

ImageDescr FROM ITAP-Image-Description; 

UnsignedByte, Longlnt, ByteString, TextString, Addresslnfo, 
DateAndTime, Number, SMSString; 



OPERATIONS IN THE DIRECTION IMS -> SN 
Bind : : = OPERATION - Timer m - 

ARGUMENT 
BindArg 
30 RESULT 

BindResultArg 
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ERRORS { 

SystemFailure, 
DataMissing, 
UnexpectedDataValue, 
5 UnknownApplicationVersion, 

BindReasonNotSupported , 
SubscriptionViolation 
} 

- Binds the IMS to the SN 
10 — Class 1 operation 

Unbind : : = OPERATION 

- Unbinds the IMS from the MSN 

- Class 5 operation 

15 

GetlmageDescr : : = OPERATION -- Timer m - 

ARGUMENT 

GetlmageDescrArg 
RESULT 

20 GetlmageDescrResultArg 
ERRORS { 

SystemFailure, 

DataMissing, 

UnexpectedDataValue, 
25 AccessDenied, 

UnknownlmageDescr, 

UnknownTerminalType 

} 

- Requests an image description from the MSN 
30 Class 1 operation 
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OPERATIONS IN THE DIRECTION SN -> IMS 
Alert ::= OPERATION 

ARGUMENT 
AlertArg 
5 ERRORS { 

SystemFailure, 
DataMissing, 
UnexpectedDataValue 
} 

10 — Alerts the IMS about an event. 

- Class 3 operation 

ERRORS 

AccessDenied ::= ERROR 
15 - This error code is returned when the SN cannot 

- access the database 

BindReasonNotSupported :: = ERROR 

- This error code is returned when a correct bind 
20 — reason is provided in the 

- bind operation but the MSN does not provided 

- any service for this specific bind reason. 

DataMissing ::= ERROR 
25 — This error code is returned when data is 

- missing, e.g. an optional parameter is missing. 



30 



SystemFailure ::= ERROR 

- The task cannot be performed due to problem in 

- another entity. 
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UnexpectedDataValue:: = ERROR 

- This error code is returned when the data value 

- is unexpected for an argument to an ITAP 

- operation. 

5 

UnknownApplication Version : : = ERROR 

- This error code is returned when the IMS binds 

- to an application version 

-- that is not supported by the SN. This is only 
10 - applicable when the IMS does 

- not have support for ITAP image descriptions. 
UnknownlmageDescr : : = ERROR 

- This error code is returned when the requested 

- image description is undefined. 



15 



20 



UnknownTerminalType ::= ERROR 

- This error code is returned when the terminal 

- type specified in the 

- getlmageDescr operation is undefined. 

SubscriptionViolation : : = ERROR 

- There is no valid subscription for the 

- subscriber. 



25 PARAMETERS 

Argument Data Types 
AlertArg SEQUENCE { 

applicationVersion [00] ApplicationVersion, 

selectedLanguage [01] Language, 

30 serviceld [02] Serviceld, 

alertTimer [03] AlertTimer DEFAULT 30, 
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aPartylnfo [04] Addresslnfo OPTIONAL, 

bPartylnfo [05] Addresslnfo OPTIONAL, 

textlnfo [06] SMSString OPTIONAL, 

subService [07] SubService OPTIONAL 

5 } 

-- If the applicationVersion in the IMS is not equal to the 

- corresponding version in the Alert operation, then the 

- IMS replies with a Bind operation. The selectedLanguage 

- parameter indicates the language that is currently 
10 ~ selected for this subscriber. Serviceld defines the 

- alert reason. For terminals that have support for 

~ image descriptions the serviceld is equal to the start 
image that shall be displayed and evaluated. Alert timer 

- is invoked in the IMS upon reception of the Alert 

15 - operation. If the timer expires an Unbind operation is 

- sent to the service node. The timer is cleared when 

- the first ITAP operation is sent from the IMS. 

- APartylnfo and bPartylnfo can be used to transfer address 

- information about the a-party and b-party. Textlnfo can 
20 - be used to send an arbitrary text string that can be 

- presented for the service user. 

- The subService is used to indicate which parts of the 

- application that is included in the subscription. 

25 BindArg : : = SEQUENCE { 

applicationVersion [00] ApplicationVersion, 

requestedLanguage [01] Language, 

bindReason [02] BindReason, 

supportOflmage [03] supportOflmage DEFAULT TRUE 

30 } 
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10 



15 



20 



25 



30 



BindResultArg :: = SEQUENCE { 
applicationVersion 
selectedLanguage 
serviceld 
clearlmageCache 

imagesToClear 

aPartyinfo 

bPartylnfo 

textlnfo 

subService 

nameOfAppl 

initSessionlncomingCall 

initSessionCallWaiting 



[00] ApplicationVersion, 
[01] Language, 
[02] Serviceld, 
[03] ClearlmageCache 

DEFAULT FALSE, 
[04] SEQUENCE (SIZE(1 . . 16)) OF 

Imageld OPTIONAL, 
[05] Addresslnfo OPTIONAL, 
[06] Addresslnfo OPTIONAL, 
[07] SMSString OPTIONAL, 
[08] SubService OPTIONAL, 
[09] SMSString OPTIONAL, 
[10] BOOLEAN OPTIONAL, 
[11] BOOLEAN OPTIONAL 



} 

- If MSN replies with a new applicationVersion, the IMS has 

- to clear all or a part of the image descriptions stored 

- in the cache. If clearlmageCache is TRUE the image 

- descriptions defined by imagesToClear are cleared. If 

-- clearlmageCache is TRUE and imagesToClear is not provided 

- the entire cache shall be cleared. If the IMS does 

- not support image descriptions and the application 

- version for the IMS is not equal to the application 

- version in the service node, then the session is closed. 

- IMS checks if it has image descriptions for the language 

- that is supported (= selected) by the SN. 

- Depending on the size of the IMS cache, it could be 

- necessary to clear existing image descriptions in the IMS 

- in order to get space for the selected language image 

- descriptions. The serviceld is equal to the start image 
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~ description that will be displayed and evaluated. 

- APartylnfo and bPartylnfo can be used to transfer address 

- information about the a-party and b-party. 

- Textlnfo can be used to send an arbitrary text string 
that can be presented for the service user. 

- nameOfAppl, initSessionlncomingCall or 

- initSessionCallWaiting is only returned when the bind 

- reason is "initSubsription" in the Bind invoke. 

- NameOfAppl is the name of the application. This text can 
be used to present a menu on the local MMI for accessing 

- the application. 

- InitSessionlncomingCall/initSessionCallWaiting 

- indicates whether an ITAP session shall be established 

- when there is a new incoming call or call waiting 

- indication. 

- The subService is used to indicate which parts 

- of the application that is included in the subscription. 

GetlmageDescrArg ::= SEQUENCE { 

imageld [00] Imageld, 

terminalType [01] TerminalType OPTIONAL 

} 

GetlmageDescrResultArg ::= SEQUENCE { 

imageDescr [00] ImageDescr 

} 

- The requested image description is identified by the 

- image id and terminal type. If the terminal type is not 

- provided the service node selects an image description 

- from the default set. 

~ If the service node supports different languages, then 
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-- the selected language during bind shall be used for 
- identifying the correct image description. 



Common Data Types 
5 Address ::= CHOICE{ 



distributionList 


[00] 


DistributionListld, 


number 


[01] 


Number, 


xl21address 


[02] 


Number, 


eMail 


[03] 


SMSString (SIZE(L.63)), 


restricted 


[04] 


NULL 



} 

- Specifies possible address types. Restricted is used when 

- a-number presentation is restricted. 



15 Addresslnfo ::= SEQUENCE { 

address Address, 

name SMSString (SIZE( 1 . . 63)) OPTIONAL 

} 

— Specifies the address and the name of the addressee. 

20 

AlertTimer ::= INTEGER (0.. 65535) 

~ Specifies the IMS user idle time when an Alert has been 

~ received. 



25 ApplicationVersion : : = INTEGER (0. .65535) 
— Version of the current application. 

BindReason ::= ENUMERATED { 
incorrectApplicationVersion (0), 
30 incomingCall (1), 

call Waiting (2), 
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userlnitiatedSession (3) , 

initSubscription (4) 

} 

~ Indicates the reason for Bind, e.g new incoming call, 
5 wrong application version, user initiated session or 

- subscription management. 

ByteString ::= OCTET STRING (SIZE(1..255)) 
-- Octet string 

10 

ClearlmageCache ::= BOOLEAN 

- TRUE indicates that the whole or a part of the IMS image 

- cache should be cleared. 

15 DateAndTime : : = OCTET STRING (SIZE(6)) 
YYMMDDHHSS, BCD coded 

- E.g. 1995-12-31, 12:15 is coded: 59 21 13 21 51 00 



DistributionListld : : = INTEGER (0. . 15) 
20 -Identity of distribution list. 

Imageld : : = INTEGER (0. .65535) 

— Unique identity of an IMS image associated with ITAP. 



25 Language :: = ENUMERATED { 



german (0), 

english (1), 

italian (2), 

french (3), 

30 Spanish (4), 

dutch (5), 
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sweaisn 


W> 


aanisn 


('), 


Portuguese 


(o)> 


finnish 


(9), 


norwegian 


(10), 


greek 


(11), 


turkish 


(12) 



} 

- Language selected for MS. 

10 

Longlnt ::= INTEGER (-2147483647.. 2147483647) 

- Signed integer within the range -2147483647 to 2147483647 

Number ::= TBCDString (SIZE (1..14)) 
15 — A telephone number in BCD format. 

Serviceld : : = INTEGER (0. .65535) 

« Indicates the application that shall be started in the 

- IMS. If the IMS supports image descriptions, serviceld 
20 — defines the first image description that shall be 

- displayed and evaluated. 

SMSString ::= OCTET STRING (SIZE(1..140)) 
~ A string coded according to the 7-bit SMS default 
25 - alphabet as specified in GSM 03.38. 

SubService ::= OCTET STRING (SIZE(1..4)) 

- A string indicating which service that are included in a 

- subscription. Bit 1 in the first octet indicates if the 
30 - first sub service is included, bit 2 in the first octet 

- indicates if the second sub service is included... It is 
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- possible to have 32 different sub services. 

- The interpretation of the different bits is application ~ specific and shall be defined 
together with the 

- application specific operations. 

5 

SupportOflmage ::= BOOLEAN 

-TRUE indicates that the IMS supports image descriptions 

TBCDString ::= OCTET STRING (SIZE (1..64)) 
10 ~ A packed digit string. Digits 0 to 9, *, #, a, b, c two - digits per octet. 
-- Each digit encoded as 0000 to 1001(0 to 9), 1010 (*), 

- 1011 (#) 1100 (a), 1101 (b) or 1110 (c). 1111 is used as 

- filler when there is an odd number of digits. First digit 

- is stored in bit 0 - 3 of the first octet. 

15 

TerminalType ::= SMSString (SIZE(1..31)) 

- IMS terminal type, e.g "GH 338" 

TextString ::= IA5String (SIZE(1..255» 
20 ~ Text string 

UnsignedByte ::= INTEGER (0..255) 

- Unsigned integer within the range 0-255 

:= 1 
:= 2 
:= 3 
:= 4 



25 OPERATION CODES 

bind Bind 
unbind Unbind 

getlmageDescr GetlmageDescr 
alert Alert 



30 
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ERROR CODES 

accessDenied AccessDenied : : = 1 

bindReasonNotSupported BindReasonNotSupported : : = 2 

dataMissing DataMissing : : = 3 

5 systemFailure SystemFailure ::= 4 

unexpectedDataValue UnexpectedDataValue : : = 5 

unknownApplicationVersion UnknownApplicationVersion : : = 6 

unknownlmageDescr UnknownlmageDescr ::= 7 

unknownTerminalType UnknownTerminalType : : = 8 

10 subscriptionViolation SubscriptionViolation : : = 9 
END 



RULES AND RESTRICTIONS FOR APPLICATION DEPENDENT 
ITAP OPERATIONS 

15 

1. These operations shall all be of ROSE class 1. 

2. The structure of each operation specification is: 

MyOperation ::= OPERATION 
20 ARGUMENT 

MyArg 

RESULT 

MyResultArg 

25 

ERRORS { 

My Error 1 
MyError2 



30 
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} 

5 — Description of MyOperation 

3. The operation codes for the application dependent ITAP operations 
shall be within the range of 10 to 255 as operation codes 1 to 9 are reserved for the 

10 basic ITAP operations. 

4. Each operation argument ("MyArg", "MyResultArg") shall always be 
specified as a SEQUENCE data type. This is also valid even if the argument contains 
only one element. 



15 A limited number of data types shall be used for the elements in the 

operation arguments. The allowed data types are: 

BOOLEAN, 

UnsignedByte; 

Longlnt, 
20 ByteString, 

TextString, 

Addresslnfo, 

DateAndTime, 

Number, 
25 SMSString 

Each one of these data types could be used as a primitive data type or 
as a "SEQUENCE OF" data type. 



30 



It is not allowed to specify value range or sizes range of a specific 
element. If the value range or size range specified for the type of the element must 
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be further decreased, this shall be indicated as a comment, not as ASN.l syntax. The 
reason for this is that if PER is used, the length field of a "sized element" contains 
the number of bits that is required for the maximum size. Also, the number of bits 
required for the value field of a certain "value element" depends on the maximum 
5 value specified. This makes the number of bits for the length field or the value field 
variable. Variable field lengths is difficult to handle by the PER encoder/decoder in 
the MS as it must be generic. 

The tagging shall be: 
10 - Sequential (start with tag 0) 

- Context-specific 

- Implicit 

Optional parameters shall be specified at the end of the operation argument. 

15 

DEFAULT is not allowed. 

See the following example: 

20 " 

MyArg ::= SEQUENCE { 



pari [00] 
par2 [01] 
par3 [02] 



TextString 

SEQUENCE OF UnsignedByte OPTIONAL 



BOOLEAN 



25 } 



- Size of par2 is maximum 128. 

- par3 may have maximum 5 occurrences of 

- UnsignedByte 



30 
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5. No parameters are allowed for the error types. The error codes shall 

be in the range of 20 to 255 as error codes 1 - 19 are reserved for the basic ITAP 
operations. 

5 6. The application dependent ITAP operations shall be specified in a 

separate ASN. 1 module. This module shall import the specification of the allowed 
data types from the basic ITAP ASN.l module. 

The focus of this description will now be on a more detailed description 
10 of image descriptions. The image descriptions mainly put requirements on suppliers 
of the IMS 1401, because from the point of view of the SN 1409, the image 
description is just a resource that needs to be loaded using the ITAP 
GetlmageDescription operation. 

The following specifications are made with ASN.l syntax. Data types 
15 that are not specified here were specified above in the sections discussing ITAP 
Operations. 

SPECIFICATIONS 
IMAGE DESCRIPTIONS, GENERAL STRUCTURE 

20 

ITAP-Image-Description DEFINITIONS IMPLICIT TAGS : : = 

BEGIN 

IMPORTS 

UnsignedByte, Longlnt, ByteString, TextString, 
25 Addresslnfo, DateAndTime, Number, SMSString FROM 

ITAP-operations; 

EXPORTS 

ImageDescr; 
ImageDescr ::= SEQUENCE { 

30 

— Image header string. 



header 
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[00] SMSString OPTIONAL, 



— Declaration of registers 
registerDeclarations [01] SEQUENCE 

(SIZE(1..16» OF 
RegisterDefinition 
OPTIONAL, 

— Actions that shall be executed when a logical 

— function is invoked 

logicalFunctions [02] SEQUENCE (SIZE(1 . .7)) OF 

LogicalFunction 
OPTIONAL, 

— Action that shall be executed when the 

— image description is entered. 

action [03] SEQUENCE (SIZE(1 . .32)) OF 

Actionltem OPTIONAL, 

— Build up rest image as a sequence of 

— different MMI objects. 

imageObjects [04] SEQUENCE (SIZE(1 . .32)) OF 

ImageObject OPTIONAL 



Main structure of an image description. 

When an image description is activated, the IMS shall do 

the following procedures: 

1. Allocate memory for the declared registers. 

2. . Set up new definitions for the logical functions. 

3. Execute the action. The action items are evaluated 
in sequential order. If a new image description 
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10 



-4. 
- 5. 

~ 6. 



15 



20 



is activated in the action, the IMS shall fetch 
the new image description and evaluate the new 
image description, see step 1. An action can 
never be interrupted. If the IMS receives events 
during execution of an action, the event shall be 
pending in an event queue. The action associated 
with a pending event shall be executed when the 
IMS is idle and fetching the next event from the 
event queue. 
Display the header. 

Display the image objects, including field and 
list contents. 

Get next event. The IMS shall fetch next event 
from the event queue. If there is no event, the 
IMS shall remain in idle mode and wait for the 
next event. The events shall have the following 
priority order, in decreasing priority order: 

1 . Indication and disconnect indication 

2. Timeout 

3. User input. 

Upon reception of an event, execute the associated 
action as described in step 3. 



25 
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:= CHOICE { 






list 


[00] 


SEQUENCE (SIZE(1..8» OF ListEntry, 


textField 


[01] 


TextField, 


integerField 


[02] 


IntegerField, 


dateAndTimeField 


[03] 


DateAndTimeField, 


optionField 


[04] 


OptionField, 


addressField 


[05] 


AddressField, 


numberField 


[06] 


NumberField, 
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menu 



text 



newline 



[08] SMSString, 
[09] NULL, 

[10] SEQUENCE (SIZE(1 . . 16)) OF 



icon 



MenuOption, 
[11] Iconld 



- An image object. There can only be one menu or list 
~ objects within one image object. 



- Registers are used to store data locally in the IMS. A 

- register is allocated when the image description that 
» defines the register becomes active, i.e. when 

- display Image is executed locally in the IMS. Once the 

- register is allocated it remains allocated until the ITAP 

- session is ended or a new register is allocated with the 



- same identity. As long as the register is allocated it 
-- shall be possible to refer to that register in other 

image descriptions. 

A register can be associated with a field or a list that 

- will display the contents of a register. Furthermore a 

- register can be associated with in- and outparameters to 

- local or remote functions. The register can either be a 

- vector register or register just containing one entry. 

~ When the register is a vector it is possible to access an 

- entry in the vector by providing an vector index. 



REGISTER DATA TYPES 



RegisterDeclaration SEQUENCE { 

identity [00] Registerld, 

size [01] INTEGER (1 . . 128) DEFAULT 1 
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} 

The size parameter indicates whether the register is a 

- vector or not. If the size is 1 , the register shall be 

— considered as a simple register. 

5 

RegisterDefinition ::= CHOICE { 



bool 


[00] 


RegisterDeclaration, 


shortlnt 


[01] 


RegisterDeclaration, 


int 


[02] 


RegisterDeclaration, 


octetString 


[03] 


RegisterDeclaration, 


text 


[04] 


RegisterDeclaration, 


address 


[05] 


RegisterDeclaration, 


dateAndTime 


[06] 


RegisterDeclaration, 


number 


[07] 


RegisterDeclaration, 


smsString 


[08] 


RegisterDeclaration 



} 

— The data type of the register is defined by the unique 

— tag. 

20 OneRegisterEntry ::= CHOICE { 

simpleValue [00] Registerld, 

simpleValuelnVector [01] OneRegisterEntrylnVector 

} 

25 Reference to a register entry. The reference can be a 

— reference to register that is not a vector or a reference 

— to an entry within a vector register. For a vector 

— register the vector index must be provided as well. 

30 OneRegisterEntrylnVector SEQUENCE { 

registerld [00] Registerld, 
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vectorlndex Vectorlndex 

} 

- The OneRegisterEntrylnVector is used to refer to an entry 

- within a vector register. 

Registerld ::= INTEGER (0..255) 

- Identity of a register. 



Vectorlndex : : = CHOICE { 
10 index [00] INTEGER (0.. 127), 

selectedListRow [01] SelectedListRow, 
simpleValue [02] Registerld 

} 

- A vector index can either be a fix value, selected list 
15 — row or integer value in a register. If the index is 

- stored in a register the register must be of type Longlnt -- or UnsignedByte. Note 
~ since vector index can be of selectedListRow, it is possible to design image 

- descriptions where field contents is dependent of selected list row in a list object. 

- Therefore the IMS must be able to update these fields when the service user is 
20 — scrolling a list object. 

ACTION DATA TYPES 

- Following terms are used for parameters: 

- simpleValue, a value from a register that is not a vector. The value is identified by 
25 — just a register identity. 

- Register id 1 

- simpleVector, values from a register that is a vector. 

-The entire vector will be passed as parameter. The vector is identified by a register 
30 - identity. 

- Register id 1 
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- simpleValuelnVector, a value from a register entry within a register vector. The 

- value is identified by the register identity and a vector index. 

- Register id 1, vector index 3 



10 



15 



20 



Actionltem ::= CHOICE { 

localFunction [00] 

remoteFunction [01] 

displaylmage [02] 

conditionalStatement [03] 

labelStatement [04] 

endStatement [05] 



LocalFunction, 

RemoteFunction, 

Imageld, 

ConditionalStatement, 

Label, 

NULL 



25 



} 

- Different items that can be combined to an action. "localFunction" defines a local 
function that shall be executed in the IMS. "remoteFunction" defines a service node 

- functions that shall be executed. 

- The Displaylmage action item is used to display a new image description. When a 

- displaylmage is executed, the evaluation of the current image discription shall be 

- interrupted and the new image description shall be displayed. 

- The conditionalStatement and labelStatement are related. The conditionalStatement 

- defines a logical expression that should be evaluated. 

- Depending on the result from the evaluation the conditionalStatement defines where 

- the execution shall continue by referring to one or two labelStatements. The 

- labelStatement is the actual point in the action where the execution shall continue. 

- The endStatement indicates that the execution of an action shall be stopped 

- immediately. 
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ConditionalStatement ::= SEQUENCE { 

expression [00] Expression, 

trueLabel [01] Label OPTIONAL, 

falseLabel [02] Label OPTIONAL 

} 

- Specifies a conditional statement. The expression defines that expression that shall 
-- be evaluated. True and false label defines the identity of the label where the 

- execution shall continue. The refereed label must be defined within the same action. 

- At least one of the parameters trueLabel and falseLabel must be defined. If one of 

- the parameters is omitted, the execution will continue at the next actionltem for the 

- corresponding label. 

Expression ::= SEQUENCE { 

parameter [00] SEQUENCE (SIZE(1.. 2)) OF 

ExpressionParameter, 
operator [01] Operator OPTIONAL 

} 

- Specifies a expression that shall be evaluated. The expression shall be evaluated 
-- from left to right ("firstParameter" "operator" "secondParameter"). The first and 

- second parameter must always be of the same type with the following exceptions: 

- UnsignedByte can be evaluated with an INTEGER and a TextString can be 

- evaluated with a SMSString. The secondParameter and operator can be omitted if 
-- the firstParameter is of type BOOLEAN. 
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ExpressionParameter ::= CHOICE { 



V\/\rv1 
DUOI 


mm 
[00J 


BUULbAN , 


shorlnt 


[01] 


T T * il > 

Unsignedbyte, 


nit 


[02] 


Longlnt, 


octetS tring 


[03] 


ByteStnng, 


IcXl 


[04] 


TextString, 


address 


[05] 


Addresslnfo, 


aateAna i une 


[06] 


DateAndTime, 


number 


[07] 


Number, 


smsString 


[08] 


SMSString, 


simpleValue 


[09] 


Registerld, 


simpleValuelnVector 


[10] 


OneRegisterEntrylnVector, 


selectedListRow 


[11] 


SelectedListRow 



} 

15 ~ Specifies a parameter to an expression. The parameter could be: 

- a fixed value 

- a simple register value 

- a simple value within a vector 

- a selected list row 



20 
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InParameter ::= CHOICE { 



1 1 

bool 


[00] 


BOOLEAN, 


vectorOfBool 


[01] 


SEQUENCE OF BOOLEAN, 


shorlnt 


[02] 


UnsignedByte, 


vectorOfShorlnt 


[03] 


SEQUENCE OF UnsignedByte 


int 


[04] 


Longlnt, 


vectorOflnt 


[05] 


SEQUENCE OF Longlnt, 


octetString 


[06] 


ByteString, 


vectorOfOctetString 


[07] 


SEQUENCE OF ByteString, 


text 


[08] 


TextString, 


vectorOfText 


[09] 


SEQUENCE OF TextString, 


address 


[10] 


Addresslnfo, 


vectorOfAddress 


[11] 


SEQUENCE OF Addresslnfo, 


dateAndTime 


[12] 


DateAndTime, 


vectorOfdateAndTime 


[13] 


SEQUENCE OF DateAndTime 


number 


[14] 


Number, 


vectorOfNumber 


[15] 


SEQUENCE OF Number, 


smsString 


[16] 


SMSString, 


vectorOfSMSString 


[17] 


SEQUENCE OF SMSString, 


simpleValue 


[18] 


Registerld, 


simpleVector 


[19] 


Registerld, 


simpleValuelnVector 


[20] 


OneRegisterEntrylnVector , 


selectedListRow 


[21] 


SelectedListRow, 


noValue 


[22] 


NULL 
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- Specifies an inparameter to a function call. The inparameter could be: 

- a fixed value or a sequence of fixed values. 

- a simple register value 

- a register which is a vector 

5 ~ a simple value within a vector 

- a selected list row 

- a ho value. Used for optional parameters. 

Label ::= INTEGER (0.. 255) 
10 - Defines the identity of a label. The execution can only be transferred to a label 

- within the same action. 



15 



20 



25 



LocalFunction ::= SEQUENCE { 
msFunctionld 
inParameterList 



outParameterList 



errorCode 
errorLabel 



[00] MsFunctionld, 
[01] SEQUENCE 

(SIZE(1.. maxNoOfParameters)) OF 

InParameter OPTIONAL, 
[02] SEQUENCE 

(SIZE(1.. maxNoOfParameters)) OF 

OutParameter OPTIONAL, 
[03] Registerld OPTIONAL, 
[04] Label OPTIONAL 



} 

- Specifies a call to a local function from an image description. 

- If a fatal error occurs and the function could not be executed the execution will be 

- transferred to the error label. If no error label is provided and a fatal error occurs, 

- fatal error handling shall be that the ITAP session is terminated with the ITAP 
~ operation Unbind. 
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MsFunctionld ::= ENUMERATED { 

display ErrorMessage (0) , 

storeSessionlnitiatedParam (1), 

setMenuEntry Status (2) , 

addRegisterEntry (3), 

insertRegisterEntry (4), 

removeRegisterEntry (5) , 

searchRegister (6), 

sortRegister (7), 

mergeRegister (8) 

clearRegister (9), 

setRegister (10), 

incrementRegister (11), 

decrementRegister (12), 

copyRegister (13), 

executeOptionNo (14), 

exitlTAPControl (15), 

startNewITAPSession (16), 

startTimer (17), 

stopTimer (18), 

acceptlncomingCall ( 19) , 

disconnectCall (20) , 

setUpCall (21), 

callHold (22), 

call Active (23), 

multiParty (24), 

removeCallFromMultiParty (25) , 

callTransfer (26), 



10 
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sendDTMF (27), 

setDTMFMode (28), 

enquirySM (29), 

sendSM (30), 

replySM (31), 

getSM (32) 

deleteSM (33), 

commandSM (34), 

generatelndication (35), 

stoplndication (36), 

displaylndication (37), 

removeDisplaylndication (38), 

15 setStatusLine (39), 

enquiry ByAddress (40), 

addAddressBookEntry (41) 

updateAddressBookEntry (42), 

20 removeAddressBookEntry (43) 

} 

— Unique identity of a function in the IMS: 

maxNoOfParameters INTEGER : : = 16 
25 — Max number of in and out parameters. 



OperationCode ::= INTEGER (10.. 255) 

- Defines the function that shall be executed in the SN. 
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Operator ::= ENUMERATED { 



lessThan 


(0), 


greaterThan 


(1), 


lessOrEqual 


(2), 


greaterOrEqual 


(3), 


equal 


(4), 


notEqual 


(5), 


logicalAnd 


(6), 


logicalOr 


(7), 


logicalExlusiveOr 


(8) 



10 

} 

~ All possible operators. The operators are specified in decreasing 

- precedence, i.e. logicalOr has lower precedence than logicalAnd. 

15 OutParameter ::= CHOICE { 

simpleValue [00] Registerld, 

simpleVector [01] Registerld, 

simpleValuelnVector [02] OneRegisterEntrylnVector, 

} 

20 Specifies an outparameter to a function call. The outparameter could be: 

- a simple register value 

— a register which is a vector 

— a simple value within a vector 



RemoteFunction ::= SEQUENCE { 

operationCode [00] 
inParameterList [01] 

noOfOptionallnPar [02] 
outParameterList [03] 

noOfOptionalOutPar [04] 

errorCode [05] 
errorLabel [06] 
timeOut [07] 

} 

- Specifies a call to a remote function from an image description: 

-- Number of optional parameters must be specified so the IMS knows how the 
-- remote operation shall be encoded/decode. Timeout specifies the number of 

- seconds before there shall be response on an outstanding request. If no response is 

- received within the specified time, the signalling connection will be closed. If a 

- fatal error occurs and the function could not be executed, the execution will be 

- transferred to the error label. If no error label is provided and a fatal error occurs, 
-- fatal error handling shall be that the ITAP session is terminated with the ITAP 

- operation Unbind. 

TimeOut ::= INTEGER (0.. 65535) 

- Defines the timeout time in number of seconds. 

MENU DATA TYPES 
Iconld ::= INTEGER (0.. 65535) 
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OperationCode, 
SEQUENCE 

(SIZE(1.. maxNoOfParameters)) OF 
InParameter OPTIONAL, 
INTEGER (0.. maxNoOfParameters) 
DEFAULT 0, 
SEQUENCE 

(SIZE(1.. maxNoOfParameters)) OF 
OutParameter OPTIONAL, 
INTEGER (0.. maxNoOfParameters) 
DEFAULT 0, 
Registerld OPTIONAL, 
Label OPTIONAL, 
TimeOut DEFAULT 30 
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- Identity on graphical resource stored locally in the IMS! Icons can only be used on 

- graphical IMS. The resource associated with a certain Iconld is defined by the 
-terminal supplier. 

5 MenuOption ::= SEQUENCE { 



- Specifies one row (option) in a menu, i.e what will be displayed and the functions 
~ to call when the option is selected. It is up to the IMS to decide how the menu is 
~ presented to the user. The "icon" parameter refers to a local icon stored in the 

- IMS. The icon parameter is only applicable for graphical terminals. 

15 - SubServiceStatus indicates if the menu option shall be displayed or not. If the 

- service is not included in the subscription, the menu option will always be disabled. 

OptionTextltem ::= CHOICE { 



optionText [00] 
action [01] 
icon [02] 



SEQUENCE (SIZE(1..4» OF OptionTextltem, 
SEQUENCE (SIZE(1..32)) OF Actionltem, 
Iconld OPTIONAL, 
[03] INTEGER (1 . .32) OPTIONAL 



SubServiceStatus 



10 } 



plainText 



[00] 
[01] 
[02] 
[03] 
[04] 



SMSString, 



20 



dateAndTimeField 



addressField 



textField 



integerField 



TextField, - Note: Only output field 
IntegerField, ~ Note: Only output field 
AddressField, - Note: Only output field 
DateAndTimeField - Note: Only output 



- field 



25 } 



- The text of each option row could consists of a sequence of these items. It 

- is up to the IMS to decide how the option text is formatted on the display. 



30 



LIST DATA TYPES 



ListEntry ::= SEQUENCE { 
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register 


[00] 


Registerld, 


selectedRegister 


[01] 


Registerld, 


possibleSelections 


[02] 


INTEGER DEFAULT 1, 


length 


[03] 


INTEGER (1..64) DEFAULT 12, 


conversionList 


[04] 


SEQUENCE (SIZE(1..16)) OF 






Conversionltem OPTIONAL 



} 

- Specifies each entry in a list row. The referenced register contains the data to be 

- included in each row of the list, "length" defines the length of each entry and 
10 - conversion defines an alternative presentation, e.g. the INTEGER 1 shall be 

- presented as the text string "YES". For presentation of address information same 

- rules are valid as for address fields, see section entitled "INPUT/OUTPUT FIELD 

- DATATYPES". 

- SelectedRegister contains the value of the rows that has been selected in the list. If 
15 - one row has been selected the selectedRegister will contain one entry. If two rows 

- has been selected the register will contain 2 entries. If no selection has been done, 

- the register will be empty. Number of possible selections are defined by 
possibleSelections parameter. 



20 



25 



Conversionltem ::= SEQUENCE { 

text [00] 
value 

icon [02] 



} 



SMSString, 
GenericITAPTypes, 
Iconld OPTIONAL 



Specifies a conversion from a value to a text string. An icon 
can be associated with the conversion for graphical terminals. 
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GenericITAPTypes ::= CHOICE { 





bool 


[00] 


BOOLEAN, 




shorlnt 


[01] 


Unsignedbyte, 




int 


[02] 


Longlnt, 


5 


octetString 


[03] 


ByteString, 




text 


[04] 


TextString, 




address 


[05] 


Addresslnfo, 




dateAndTime 


[06] 


DateAndTime, 




number 


[07] 


Number, 


10 


smsString 


[08] 


SMSString, 



— ITAP basic data types. 

SelectedListRow NULL 
15 - This type specifies the selected list row. IMS calculates this value. First list row 

- has number 0 



INPUT/OUTPUT FIELD DATA TYPES 
AddressField : : = SEQUENCE { 
20 register 
labelText 
length 
inputField 
typeOfAddress 

25 } 



OneRegisterEntry, 
[01] SMSString OPTIONAL, 
[02] INTEGER (1 . .64) DEFAULT 16, 
[03] BOOLEAN DEFAULT TRUE, 
[04] TypeOfAddress DEFAULT number 
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- Specifies an address output or input/output field. The register is of type 

- Addresslnfo or Number. The following rules are defined for the presentation 

- of a register that is of type Addresslnfo: 

- 1. If a-address is available, the IMS shall search for the address in the local 

address book and display the name found in the address book. 

- 2. If name is provided by the network and the entry is not found in the local 

address book, the name provided by the network shall be displayed. 

- 3. If name is not available but the address is available, the address shall be 

displayed. 

- The subscriber shall have the possibility to toggle between the name and 

- the address. 

- Register of type Number shall always be displayed as a number. 



IntegerField :: = SEQUENCE { 
register 

labelText [01] 
min [02] 
max [03] 
inputField [04] 

} 



OneRegisterEntry, 
SMSString OPTIONAL, 
Longlnt DEFAULT 0, 
Longlnt DEFAULT 65535, 
BOOLEAN DEFAULT TRUE 



-- Specifies an integer output or input/output field. The register is of some 
- type of signed or unsigned integer type. 



NumberField ::= SEQUENCE { 
register 
labelText 
length 
inputField 

} 



[01] 
[02] 
[03] 



OneRegisterEntry , 
SMSString OPTIONAL, 
INTEGER (1..28) DEFAULT 12, 
BOOLEAN DEFAULT TRUE 
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~ Specifies a Number output or input/output field. The register 
~ is of type Number. 



OptionField ::= SEQUENCE { 
5 register OptionRegister, 

selectionList [01] SEQUENCE (SIZE(1.. 16)) OF 

Conversionltem, 
labelText [02] SMSString OPTIONAL, 

moreThanOneAllowed [03] BOOLEAN DEFAULT FALSE 

10 } 

- Specifies a general selection input/output field. The IMS can present this as 

- a menu, as check boxes, as radio buttons, as a selection field, as 

- softkeys etc. When a selection is done, the register contains the value 

~ specified by the Conversionltem. If "moreThanOneAllowed" is FALSE the 
15 - register will always contain one value, i.e. the service user must make one 

- selection. If "moreThanOneAllowed" is true, the first selected item value is 
~ stored in index 0 of the register, the second selected item value is stored in 

- index 1 etc. If there is no selections the register will be empty. 

20 OptionRegister ::= CHOICE { 

simpleValue [00] Registerld, 

simpleValuelnVector [01] OneRegisterEntrylnVector, 

simpleVector [02] Registerld 

} 

25 - Specifies a register associated with a option field. The register can be: 

- a simple register 

- an element within a register vector 

- an register vector 
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TextField ::= SEQUENCE { 
register 

labelText [01] 

lengthPerLine [02] 

noOfLines [03] 

inputField [04] 

passwdField [05] 



} 



OneRegisterEntry, 
SMSString OPTIONAL, 
INTEGER (1..128) DEFAULT 12, 
INTEGER (1.. 32) DEFAULT 1, 
BOOLEAN DEFAULT TRUE, 
BOOLEAN DEFAULT FALSE 



10 



Specifies a text output or input/output field. The register is of type 
textString. 



15 



20 



25 



OneRegisterEntry, 
SMSString OPTIONAL, 
BOOLEAN DEFAULT TRUE 



DateAndTimeField ::= SEQUENCE { 
register 

labelText [01] 
inputField [02] 
} 

- Specifies date and time output or input/output field. The register is of type 

- DateAndTime. It is up to the IMS to present the time stamp in a suitable 

- way. 

LOGICAL FUNCTION TYPES 
LogicalFunction ::= CHOICE { 



accept 


[00] 


LogicalFunctionDefinition, 


select 


[01] 


LogicalFunctionDefinition, 


send 


[02] 


LogicalFunctionDefinition, 


indication 


[03] 


LogicalFunctionDefinition, 


end 


[04] 


LogicalFunctionDefinition, 


disconnect 


[05] 


LogicalFunctionDefinition 


timeout 


[06] 


LogicalFunctionDefinition 



30 } 
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- Logical functions 0 - 4 is specified by GSM 2.30. Disconnect specifies the 

- action that shall be executed when the connection is disconnected. Timeout 

- specifies an action that shall be executed if the timer expires which is 

- started with the IMS function startTimer. The logical functions overrides the 

- standard functionality in the IMS. If there is no action associated with a 
~ logical function, standard functionality shall be provided by the IMS. 

LogicalFunctionDefinition ::= SEQUENCE { 

temporaryDefinition [00] BOOLEAN DEFAULT TRUE, 

action [01] SEQUENCE (SIZE(1 . .32)) OF 

Actionltem 

} 

- Specifies which functions to call when a standard GSM logical function 

- is executed. The definition can be temporary and just valid when the 

- current image description is active or valid during the entire ITAP session. 

COMMON DATA TYPES 
TypeOf Address ::= ENUMERATED { 

distributionList (0), 
number (1), 
X. 121 Address , (2), 
e-mail (3) 

} 

- Type of addresses 



END 



SPECIFICATION OF LOCAL IMS FUNCTIONS 
GENERAL 

In an image description a call to a Local IMS function is specified by 
the data type "LocalFunction". Included in this data type is an optional "errorLabel". 



10 
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It is, through this "errorLabel", possible to specify actions that are executed when a 
fatal error occurs. However, if no "errorLabel" is included in the function call, then 
a default error handling takes place. For all IMS functions default fatal error 
handling will be that the ITAP session is terminated with the ITAP operation Unbind. 

FUNCTIONS FOR MANIPULATING IMAGE DESCRIPTIONS AND 
IMAGE DESCRIPTION OBJECTS 

displayErrorMessage 

Displays an error message on the screen. 

Inparameters: 



Name 


Type 


Description 


errorMessage 


TextString 
(SIZE(1..40)) 


brror message 



15 Outparameters: 



Errors: 



20 

storeSessionlnitiatedParam 

Stores the text information, a-party and b-party address information 
received from SN with Alert request or Bind result in a sequence of registers. The 
function should be called from the image description that has the same number as the 
25 serviceld in the Alert or Bind response operation. 
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Inparameters: 



Name 


Type 


Description 


textlnfo 


UnsignedByte 


A register identity where the 
text information of the Alert 
request or Bind result 
narameters is stored 


APartylnfo 


UnsignedByte 


A register identity where the a- 
party information of the Alert 
request or Bind result 
parameters is stored. 


BPartylnfo 


UnsignedByte 


A register identity where the b- 
party information of the Alert 
request or Bind result 
parameters is stored. 



Outparameters: 



10 Errors: 



Description 


Code 


The function is called from an image that is not associated with 
Alert or Bind response. 


1 


A referenced register is not defined or there is a type mismatch 
between the Alert or Bind response parameter and the register. 


2 



/ 
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setMenuEntrvStatus 

Sets the status of a menu entry. The menu entry status can be "enabled" 
or "disabled". If the status is disabled, the menu entry shall not be presented for the 
service user. The default status is enabled. 
Inparameters: 



Name 


Type 


Description 


menuEntry 


UnsignedByte 


The number of the menu entry. 
The entry can be in the range of 
1 - 16. 


EnabledEntr 

y 


BOOLEAN 


If TRUE the entry will be 
enabled. If FALSE the entry 
will be disabled. 



Outparameters: 



Errors: 



Description 


Code 


Menu entry is out of range . 


1 
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addRegisterEntrv 

Adds an item to a vector register. It is possible to add the item in start 
of vector, end of vector or in sort order. The function returns the index where the 
item was inserted. The entries with higher index than the inserted index, are moved 

5 to one index higher. If the vector is filled with entries and insert mode is start of 
vector or in sort order, the last entry shall be removed and the new item shall be 
inserted. If the vector is filled and insert mode is end of vector, an error shall be 
returned indicating that the maximum number of entries has been exceeded. Note: 
insert mode "in sort order" is only possible to use for sorted vectors. 

10 Inparameters: 



Name 


Type 


Description 


registerld 


UnsignedByte 


Register identity. 


newltem 


GenericITAPTypes 


Item that shall be inserted. 


insertMode 


UnsignedByte 


0 = Start of vector 

1 = End of vector 

2 = In sort order of vector 



15 

Outparameters: 



Name 


Type 


Description 


index 


UnsignedByte 


Index where the item was , 
inserted. 



20 Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


The value to set is of another type than the register 


2 


Undefined insert mode 


3 


Max number of entries exceeded 


4 
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insertRegisterEntrv 

Inserts an entry in a vector register. The entries with higher index than 
the inserted index, are moved to one index higher. If the vector is filled with entries, 
the last entry shall be removed and the new entry shall be inserted. 
5 Inparameters: 



Name 


Type 


Description 


registerld 


UnsignedByte 


Register identity. 


newltem 


GenericITAPTypes 


Item that shall be inserted. 


index 


UnsignedByte 


Index where the item shall be 
inserted. 



Outparameters: 



Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


The value to set is of another type than the register 


2 


Index out of range 


3 



20 
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removeRegisterEntrv 

Removes an entry in a sequence of vector registers. The entries with 
higher index than the removed index, are moved to one index lower, in order to fill 
out the gap. 
Inparameters: 



Name 


Type 


Description 


registerList 


SEQUENCE 
(SIZE(L.8)) OF 
UnsignedByte 


A list of vector register 
identities. 


index 


UnsignedByte 


Index of entry to be removed. 



Outparameters: 



Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


Index out of range. 


2 
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searchRegister 

Searches an item in a vector register. Returns the index of the first 
entry that matches the search item. The register may not be sorted so the function 
must search the entire register for a matching item. 
5 Inparameters: 



Name 


Type 


Description 


registerld 


UnsignedByte 


Vector register identity. 


searchltem 


GenericITAPTypes 


Item to search for. 


startlndex 


UnsignedByte 


Index in vector where to start 
searching. 



Outparameters: 



Name 


Type 


Description 


index 


UnsignedByte 


Index to item if it is found. 



15 Errors; 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


Item was not found in register. 


2 
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sortRegister 

Sorts a vector register and an additional list of vector registers. Input 
to the function is the registers that shall be sorted. 
Inparameters: 



Name 


Type 


Description 


sortRegister 


SEQUENCE 
(SIZE(1..8)) OF 
UnsignedByte 


A list of vector register which 
should be sorted. The first 
register in the sequence will be 
used to define the sort order. 


ascending 


BOOLEAN 


TRUE if registers should be 
sorted in ascending order. 



Outparameters: 



Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 
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mergeRegister 

Merges two vector registers. Both registers must be of the same type. 
The result register will get the same id as registerldl. 
Inparameters: 



Name 


Type 


Description 


registerldl 


UnsignedByte 


identity of first vector register 
and identity of result register. 


registerld2 


UnsignedByte 


Identity ot second vector 
register. 



Outparameters: 



Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


The registers are of different types. 


2 
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clearRegister 

Clears a sequence of vector registers or simple registers. 

Inparameters: 



Name 


Type 


Description 


registerList 


SEQUENCE 

(SIZE(1..8))OF 

UnsignedByte 


A list of registers to be cleared. 



Outparameters: 



10 Errors: 



Description 


Code 


A referenced register is not defined. The status of the registers 
are undefined. 


1 
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setRegister 

Sets a value in a simple register or a range of entries in a vector 
register. The value to set must be of the same type as the register. 
Inparameters: 



Name 


Type 


Description 


registerld 


UnsignedByte 


Identity of register. 


Value 


GenericITAPTypes 


Value to set. 


start index 


UnsignedByte 


Start index ot range that should 
be set. If the register is a not 
vector start and end index are 
not used. 


end index 


UnsignedByte 


End index of range that should 
be set. 



Outparameters: 



Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


The value to set is of another type than the register. 


2 
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incrementRegister 

Increments the value of a register entry. The register must be of type 
Longlnt or UnsignedByte. 
Inparameters: 



Name 


Type 


Description 


registerld 


UnsignedByte 


Identity of register. 


value 


Longlnt 


Value that the register shall be 
incremented with. 


index 


UnsignedByte 


Index in vector register. Only 
used if the register is a vector. 



10 Outparameters: 



Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


The wrong type of register 


2 
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decrementRegister 

Decrements the value of a register entry. The register must be of type 
Longlnt or UnsignedByte. 
Inparameters: 



Name 


Type 


Description 


registerld 


UnsignedByte 


Identity ot register. 


value 


Longlnt 


Value that the register shall be 
decremented with. 


index 


UnsignedByte 


Index in vector register. Only 
used if the register is a vector. 



10 Outparameters: 



Errors: 



Description 


Code 


A referenced register is not defined or is not a vector. 


1 


The wrong type of register 


2 
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copvRegister 

Copies the contents of one register to another register. Both registers 
must be of the same type and can be simple registers or vector registers. If the 
registers are vectors, then the whole vector is copied. 
5 Inparameters: 



Name 


Type 


Description 


originating 
Registerld 


UnsignedByte 


Identity of the register to copy 
from. 


destination 
Registerld 


UnsignedByte 


Identity ot the destination 
register. 



Outparameters: 



15 Errors: 



Description 


Code 


A referenced register is not defined. 


1 


The two registers are of different types or one is vector and the 
other not. 


2 
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executeOptionNo 

Executes the actions, specified for the selected menu option in a menu 
that is presented in this image. 
Inparameters: 



Name 


Type 


Description 


optionNo 


UnsignedByte 


Selected option 



Outparameters: 

10 

Errors: 



Description 


Code 


The image description where this function call is performed, 
don't have any menu object. 


1 


The selected menu option number is illegal. 


2 



exitltapControl 

20 Returns control to the basic part of the IMS. Unbind is sent to SN. 

Inparameters: 



Outparameters: 
25 - 

Errors: 



30 
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startNewITAPSession 

Starts a new ITAP session. Bind, with a new session id, will be sent to 
the SN. The capabilities of the bearer determines if the already running ITAP session 
will be temporarily interrupted, or if it will continue to run in parallel with the new 
5 ITAP session. 
Inparameters: 



Name 


Type 


Description 


bindReason 


UnsignedByte 


Reason tor establishing a new 
session. 



10 Outparameters: 



Errors: 



Description 


Code 


No response on the Bind request is received from the SN. 


1 
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startTimer 

Starts a timer. If the timer expires the action defined for the logical 
function, timeout will be executed. The timer can be cleared with the stopTimer 
function. It is only possible to start one timer. 
Inparameters: 



Name 


Type 


Description 


time 


Longlnt 


Timeout in seconds 



10 



Outparameters: 



15 



Errors: 



Description 

Timer already activated. 



Code 



stopTimer 

Stops a timer. Clears the timer that has been started with startTimer. 



Inparameters: 



20 



Outparameters: 



25 Errors: 



Description 


Code 


Timer is not activated 


1 



-107- 

CALL RELATED FUNCTIONS 
acceptlncomingCall 

Accepts a call that has been indicated in the IMS or sets the IMS in a 
mode so the next incoming call will be accepted. 
5 There are no error responses from this function. The function will 

return immediately with a call id. The call identity is always greater than or equal to 
1. 

Inparameters: 

10 

Outparameters: 



Name 


Type 


Description 


callld 


UnsignedByte 


Identity of call 



15 Errors: 



Description 


Code 


Call not accepted due to system failure. 


1 
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disconnectCall 

Disconnects a call or muiti party. 
Inparameters: 



Name 


Type 


Description 


callld 


UnsignedByte 


Identity ot call or multi party. 



Outparameters: 



10 Errors: 



Description 


Code 


Illegal call identity 


1 



setUpCall 

15 Sets up call to another party. Function immediately returns with call 

identity. 
Inparameters: 



Name 


Type 


Description 


bNumber 


Addresslnfo 


Called party number. 



Outparameters: 



Name 


Type 


Description 


callld 


UnsignedByte 


Identity of call 



25 Errors: 



Description 


Code 


Illegal bNumber. 


1 
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FUNCTIONS FOR ACCESSING GSM SUPPLEMENTARY 

SERVICES 

callHold 

Puts an active call or multi party on hold. If there is already a call on 
5 hold, that call becomes active and the identity of that call is returned. If there is no 
call on hold, callld 0 is returned. 
In parameters; 

10 Outparameters: 



Name 


Type 


Description 


callld 


UnsignedByte 


Identity of call that was on hold 
and becomes active. 


ActiveCall 


BOOLEAN 


TRUE if the call on hold 
change state to active. If there 
is no call on hold that can 
change state to active, FALSE 
is returned. 



15 Errors: 



Description 


Code 


Call not put on hold due to system failure. 


1 
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callActive 

Makes a held call or multi party active. 
Inparameters: 

5 

Outparameters: 



Name 


Type 


Description 


callld 


UnsignedByte 


Identity , of call that was on hold 
and becomes active. 



10 Errors; 



Description 


Code 


No call on hold. 


1 



multiPartv 

15 Sets up a conference call. The active call and the call on hold are 

joined in a multi party and the served mobile subscriber and the remote parties can all 
communicate with each other. The function returns the id of the multi party. 
Inparameters: 

20 

Outparameters: 



Name 


Type 


Description 


multiPartld 


UnsignedByte 


Identity of the multi party 



25 Errors: 



Description 


Code 


No active call 


1 " 


No call on hold 


2 
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removeCallFromMultiPartv 

Removes a call from a multi party. The removed call becomes active 
and the multi party call is put on hold. 
Inparameters: 



Name 


Type 


Description 


multiPartld 


UnsignedByte 


Identity ot the multi party 


callld 


UnsignedByte 


Identity of call that shall be 
removed from the multi party 



Outparameters: 



Errors; 



Description 


Code 


Illegal multi party identity 


1 


Illegal call identity 


2 
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callTransfer 

Transfers a call to another party. 
Inparameters: 



Name 


Type 


Description 


callld 


UnsignedByte 


Identity ot call 


newDest 


Addresslnfo 


New destination for call. 



Outparameters: 
Errors: 



Description 


Code 


Illegal call identity 


1 


Illegal new destination. 


2 



FUNCTIONS FOR HANDLING DTMF 
sendDTMF 

Sends a string of DTMF digits on the active call connection. 
20 Inparameters: 



Name 


Type 


Description 


DTMFString 


Number 


String of DTMF digits 



Outparameters: 

25 - 

Errors: 



30 



Description 


Code 


No active call 


1 
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setDTMFMode 

Sets DTMF mode to on or off. 
Inparameters: 



Name 


Type 


Description 


DTMFUn 


BOOLEAN 


TRUE means DTMF is on. 



Outparameters: 
Errors: 

FUNCTIONS FOR HANDLING SMS 
enquirvSM 

Enquiry regarding short messages stored in the MS-TE or SIM. 
Inparameters: 



Name 


Type 


Description 


selectedMedia 


UnsignedByte 


Selected media: 

0 = TE 

1 = SIM 

2 = all 


selectedStatus 


UnsignedByte 


Selected status: 

0 = New 

1 = Old 

2 = Saved 

3 = all 
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Outparameters: 



X Gallic 


lype 


Description 


timeStamp 


SEQUENCE OF 


States time stamp of the short 




DateAndlime 


message. 


mecuas 


oJbQUbNLb Or 


Media: 




UnsignedByte 


0 = TE 






1 = SIM 


status 


SEQUENCE OF 


Status: 




UnsignedByte 


0 = New 






1 = Old 






2 = Saved 


messageld 


SEQUENCE OJF 


Identity ot the message. 




Longlnt 




originator 


SEQUENCE OF 


Address and name of the 




Addresslnfo 


originator of the message. 



Errors: 



Description 


Code 


Access denied 


1 
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sendSM 

Sends a short message. The function uses the default values stored in 
the IMS for other parameters take can be provided for mobile originated SM, e.g. 
replay path, protocol identifier or service centre address. 
Inparameters: 



Name 


Type 


Description 


textString 


SMSString 


A text string to be sent. 


Recipient 


Addresslnfo 


Address and name of the 
receiver of the message. 


protocol- 
Identifier 


UnsignedByte 


Protocol identifier that refers to 
higher layer protocol or 
indicates interworking with a 
certain type of telematic device. 
The value is specified in GSM 
03.40 (TP-PID). 



Outparameters: 



Name 


Type 


Description 


message 
Reference 


UnsignedByte 


Message reference gives a 
reference number of the 
submitted message, see GSM 
03.40 (TP-MR) 



Errors: 



Description 


Code 


Illegal receiver destination. 


1 


Illegal protocol identifier 


2 
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replvSM 

Reply to a received short message. This function checks whether the 
reply path is requested in the original short message. If reply path is requested the 
service centre address in the original short message shall be used in the reply 
5 message. If reply path is not request the default service centre address shall be used. 
The recipient address is always fetched from the original message. 
Inparameters: 





Name 


Type 


Description 




textString 


SMSString 


A text string to be sent. 


10 


Messageld 


Longlnt 


Identity of the replied message. 


Outparameters: 




Name 


Type 


Description 


15 


message 
Reference 


UnsignedByte 


Message reference gives a 
reference number of the 
submitted message, see GSM 
03.40 (TP-MR) 



Errors: 



Description 


Code 


Illegal message identity 


1 


Illegal protocol identifier 


2 
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getSM 

Gets a short message. 
In parameters: 



Name 


lype 


Description 


messageld 


Longlnt 


Identity ot the message. ! 



Outparameters: 



Name 


Type 


Description 


textString 


SMSString 


Received text string. 



Errors: 



Description 


Code 


Access denied 


1 


Illegal messageld. 


2 



deleteSM 

Deletes a short message. 
Inparameters: 



Name 


Type 


Description 


messageld 


Longlnt 


Identity ot the message. 



Outparameters: 



Errors: 



Description 


Code 


Access denied 


1 


Illegal messageld. 


2 
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commandSM 

Send a command to the SMS-C. The following commands are defined: 
enquiry the status of a submitted message (delivered, not delivered, replaced), cancel 
a request for status report or delete a submitted message. 
Inparameters: 



Name 


Type 


Description 


message 
Reference 


UnsignedByte 


Reference of the submitted 
message, see GSM 03.40 (TP- 
MR) 


command 


UnsignedByte 


Type of command, see GSM 
03.40 (TP-CT). 



Outparameters: 



Errors: 



Description ~ ~ 


Code 


Unknown message reference 


1 


Illegal command 


2 
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FUNCTIONS ACCESSING LOCAL HARDWARE AND SOFTWARE 

OBJECTS IN THE IMS 

generatelndication 

Generates an indication, e.g. a ring tone, in the IMS. 
5 Inparameters: 



Name 


Type 


Description 


typeOf 


UnsignedByte 


Type of indication: 


Indication 




0 = incoming speech call 






1 = incoming data call 






2 = incoming fax call 






3 = incoming auxiliary speech 






call 






4 = call waiting 






5 = received SM 






6 = voice mail notification 






7 = fax notification 






8 = E-mail notification 






9-15 = extra notifications 



10 Outparameters: 



Errors: 



Description 


Code 


Illegal type of notification. 


1 
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stoplndication 

Stops an indication, e.g a ring tone, in the IMS. 
Inparameters: 



iName 


lype 


Description 


typeur 


unsignear>yte 


lype of indication: 


Indication 




0 = incoming speech call 






1 = incoming data call 






2 = incoming fax call 






3 == incoming auxiliary speech 






call 






4 = call waiting 






5 = received SM 






6 = voice mail notification 






7 = fax notification 






8 = E-mail notification 






9-15 = extra notifications 



Outparameters: 

10 

Errors: 



Description 


Code 


Illegal type of notification. 


1 
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displavlndication 

Displays an indication on the IMS display. 
Inparameters: 



Name 


1 M tmA 1 

lype 


Description 


typeUrlndica 


UnsignedlByte 


Type or indication: 


tion 




0 = incoming speech call 






1 = incoming data call 






2 = incoming fax call 






3 = incoming auxiliary speech 






call 






4 = call waiting 






5 = received SM 






6 = voice mail notification 






7 = fax notification 






8 = E-mail notification 






9-15 = extra notifications 


number 


UnsignedByte 


Number of new SM, voice 
mails etc. Only required for 
message notifications. 



10 Outparameters: 



Errors: 



Description 


Code 


Illegal type of notification. 


1 
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removeDisplavIndication 
Removes a display indication at the IMS. 
Inparameters: 



Name 


Type 


Description 


typeOflndica 


UnsignedByte 


Type of indication: 


tion 




0 = incoming speech call 






1 = incoming data call 






2 = incoming fax call 






3 = incoming auxiliary speech 






call 






4 = call waiting 






5 = received SM 






6 = voice mail notification 






7 = fax notification 






8 = E-mail notification 






9-15 = extra notifications 



Outparameters: 

10 

Errors: 



Description 


Code 


Illegal type of notification. 


1 
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setStatusLine 

Sets a status line on the IMS display. 

Inparameters: 



Name 


Type 


description 


textS tring 


TextString 
(SIZE(1..80)) 


A text string which comprises 
the status line. 



Outparameters: 



10 Errors: 
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enquiryBv Address 

Enquiries the address book about the address information for one or 
more subscribers, specified by the address. The function returns all entries that match 
the search key. 

5 

Inparameters; 



Name 


Type 


Description 


address 


Addresslnfo 


Address to subscriber. If the 
address is of length 0 all entries 
in the address book will be 
returned by the function. 



10 Outparameters: 



Name 


Type 


Description 


addressList 


SEQUENCE OF 
Addresslnfo 


List of addresses. 


IndexList 


SkQUt!NCE OP 
Longlnt 


List if unique indexes, 
identifying the entries in the 
address book. 



15 Errors: 



Description 


Code 


Access denied to address book 


1 


No entries matching the search key 


2 
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addAddressBookEntrv 
Adds an entry in the address book. 
Inparameters: 



Name 


Type 


Description 


address 


Addresslnfo 


Address to subscriber. 



Outparameters: 



Name 


Type 


Description 


index 


Longlnt 


Unique index identifying the 
entry in the address book. 



Errors: 



Description 


Code 


Access denied to address book 


1 


Address already in address book 


2 
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updateAddressBookEntrv 
Updates an entry in the address book. 
Inparameters; 



Name 


lype 


Description 


index 


Longlnt 


Unique index identifying the 
entry in the address book. 


address 


Addresslnfo 


Address to subscriber. 



Outparameters: 



Errors; 



Description 


Code 


Access denied to address book 


1 


No entry matching the index 


2 
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removeAddressBookEntry 
Removes an entry in the address book. 
Inparameters: 



Name 


Type 


Description 


index 


Longlnt 


Unique index identifying the 
entry in the address book. 



Outparameters: 



10 Errors: 



Description 


Code 


Access denied to address book 


1 


No entry matching the index 


2 



15 

The focus of this description will now be on a detailed description of 
application dependent ITAP operations for a personal access service. The abstract 
syntax of the application dependent operations follows the rules and restrictions 
defined above in the section entitled ITAP-OPERATIONS, utilizing ASN.l syntax. 

20 

SERVICE IDENTITIES 
GENERAL 

The ITAP operations Alert and Bind have the possibility of indicating 
the reason for initiating an ITAP session, (e.g. incoming call or new message). The 
25 reason is indicated by the service identity parameter. Together with the operation it is 
also possible to provide parameters that are associated with the service identity, i.e. 
text information and address information. 

This section defines the different service identities that are defined for a 
Personal Access (PA) application and how the corresponding parameters are utilized 
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for transferring application dependent parameters in the initiating ITAP operations for 
the different service identities. 

Messaging and profile management 

This will be the service identity used when the service user is accessing 
the personal access application in the service node without authentication. The service 
user shall be offered services for enquiring the mailboxes or managing the personal 
profile. No parameters are associated with the service identity. 

Incoming call 

An ITAP session for incoming calls can be established in two ways: 
network initiated and mobile initiated. A networked initiated ITAP session occurs 
when the caller is screened before the speech connection is established to the IMS 
1401. An ITAP session is mobile initiated when the establishment of the speech 
connection triggers the IMS 1401 to start a new ITAP session. The A-number and A- 
name will be sent if the information is available or if there is no caller line restriction. 
The A-name and A-number are mapped on the aPartylnfo parameter in the Alert 
invoke or Bind result. 

New message notification 

An ITAP session for message notification is always initiated from the 
network. The service node initiates an ITAP session with the ITAP operation Alert 
for indicating that a new message has been stored in the subscriber's mailbox. The 
notification information (e.g., time stamp and originator) is fetched from the SN 1409 
with the application dependant operation RetrieveNewMessagelnformation. No 
parameters are transferred. 

Screening expired notification 

An ITAP session for indicating that the screening has expired is always 
established from the network. The screening reason that has expired shall be sent as 
a text string. The screening reason is mapped on the textlnfo parameter in the Alert 
operation. The service user shall be able to set a new expiration time. 
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General Notification 

An ITAP session for notification is always established from the 
network. The notification reason shall be sent as a text string. The notification text 
is mapped on the textlnfo parameter in the Alert operation. 

5 

Set status line 

An ITAP session for setting the status line is always initiated from the 
network. The service node initiates an ITAP session with the ITAP operation Alert 
for indicating that the status text displayed in idle mode shall be changed, such as 
10 when the current screening state is changed. The status text is mapped on the textlnfo 
parameter in the Alert operation. 

Authentication 

This will be the service identity used when the service user is accessing 
15 the personal access application in the service node with authentication. The service 
user will be requested to enter the personal identification number (PIN)-Code. If the 
correct PIN-Code is entered, the service user shall be offered services for enquiring 
the mailboxes or managing the personal profile. No parameters are associated with 
the service identity. 



20 



SERVICE IDENTITIES 



messagingAndProfileManagement Serviceld 
incomingCall Serviceld 
newMessageNotification Serviceld 
25 screeningExpiredNotification Serviceld 
generalNotification Serviceld 
setStatusLine Serviceld 
authentication Serviceld 



= 1 
= 2 
= 3 
- 4 
= 5 
= 6 
= 7 



30 



SUB SERVICES 



-130- 

The PA application provides an operating environment comprised of 
individual related services, some of which are mandatory and some which are 
optional. 

It is possible to create a PA service application package comprised of 
the mandatory PA services plus the operator specific selection from the available 
optional PA services. 

The following PA services are mandatory: 
Voice mail 
Personal number 
POTS PA service 
Notification 

Operator Determined Barring 
The following PA services in the UIF are optional: 
Fax detection 
Callers choice 
Caller presentation 
Call screening 
Incoming call selection 
Call logs 
Fax mail 
E-mail 
Conversion 

An identification of which optional services are included in the service 
users subscription is indicated with the subService parameter in Bind result or Alert 
invoke. The services are mapped in the following way: 

Fax detection, bit 1 octet 1 

Callers choice, bit 2 octet 1 

Caller presentation, bit 3 octet 1 

Call screening, bit 4 octet 1 

Incoming call selection, bit 5 octet 1 

Call logs, bit 6 octet 1 
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Fax mail, bit 7 octet 1 
E-mail, bit 8 octet 1 
Conversion, bit 1 octet 2 
If the bit is 1, then the corresponding service is included in the 

subscription. 



PA SPECIFIC ITAP OPERATIONS 

The data types that are not specified below are specified in the above 
sections under the heading "ITAP - OPERATIONS". 

CALL RELATED OPERATIONS 
PA-ITAP-Operations DEFINTION IMPLICIT TAGS :: = . 
BEGIN 
IMPORTS 

OPERATION, ERROR FROM Remote-Operations-Notation 
{joint-iso-ccitt remote-operations(4) notation(O)} 
UnsignedByte, Longlnt, ByteString, TextString, Addresslnfo, 
DateAndTime, Number, SMSString FROM ITAP-operations; 

AcceptCall ::= OPERATION - Timer m 

ERRORS { 

SystemFailure, 
CallAnswered, 
FaxDetected, 
HookOn 

} 

- Accepts the incoming call and the parties will be immediately connected. 

- Class 1 operation 



CallBack ::= OPERATION Tmier 
ERRORS { 
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Call Answered, 
FaxDetected, 

AccessDeniedToResource, 
HookOn 

5 ■ > 

- A predefined message will be played to the calling party and the caller 

- number will be stored in the call back log. 

- Class 1 operation 

10 EnquiryCallSetUpStatus : : = OPERATION - Timer m - 

ERRORS { 

SystemFailure, 

NoAnswer, 

Busy, 

15 NotReachable 

} 

- Used to enquiry the call set-up status from the SN. The operation can be 

- used after successful result from SetUpCall, PlayMessage, RecordGreeting 

- or Play Greeting. 
20 — Class 1 operation 

HoldCall : : = OPERATION _ Timer m - 

ERRORS { 

CallAnswered, 
25 FaxDetected, 

HookOn 
} 

-- A message will be generated to the calling party that the incoming call will 

- be answered as soon as possible. 
30 — Class 1 operation 
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RejectCall :: = OPERATION -Timer 
ERRORS { 

CallAnswered, 

FaxDetected, 

HookOn 

} 

- The incoming call is rejected and the caller is routed to the no answer 

- destination. 

- Class 1 operation 

SetUpCall : : = OPERATION Timer 
ARGUMENT 

SetUpCallArg 
ERRORS { 
Busy, 

SystemFailure 
} 

~ Requests the Service Node to set up a call leg to a specified destination 
~ and to the IMS. The SN shall return the result when the call leg to the 

- IMS has been allocated, i.e. when the SN receives the "Alerting" indicator 

- from the network. 

- Class 1 operation 

TransferCall : : = OPERATION „ Timer i 

ARGUMENT 

TransferCallArg 
ERRORS { 

SystemFailure, 

CallAnswered, 

FaxDetected, . 

HookOn 
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} 



- The call will be transferred to a new destination. The destination can be a 

- predefined number defined by the operator or an explicit number. 

- Class 1 operation 



MESSAGING RELATED OPERATIONS 
CancelMessageDelivery : : = OPERATION 
ARGUMENT 

CancelMessageDelivery Arg 
ERRORS { 

AccessDeniedToResource, 

UnknownMedia, 

UnknownMessage 

} 

— Cancels a requested message delivery. 
Class 1 operation 



Timer m 



DeleteMessage ::= OPERATION 

ARGUMENT 

DeleteMessageArg 

ERRORS { 

AccessDeniedToResource, 

UnknownMedia, 

UnknownMessage 

} 

- Deletes one or more messages. 

— Class 1 operation 



- Timer m 



EnquiryDeliveryLog ::= OPERATION 
ARGUMENT 

EnquiryDeliveryLogArg 



- Timer m 



-135- 



RESULT 

EnquiryDeliveryLogResultArg 
ERRORS { 

Access Denied, 

UnknownMedia, 

UnknownStatus 



ARGUMENT 

EnquiryMailboxArg 
RESULT 

EnquiryMailboxResultArg 
ERRORS { 

Access Denied, 

UnknownMedia, 

UnknownStatus 



— Status enquiry regarding messages in a subscriber's mailbox, e.g. 

-- timestamp, originator, media and identity. The result indicates whether 

— there are more status entries available in the SN or not. The remaining 
-- part is retrieved by additional status enquires with the selected status 

— assigned to more information. 

— Class 1 operation 




EnquiryMailbox ::= OPERATION 



- Timer m 



FastForwarding :: = OPERATION 
ERRORS { 

IllegalOperation 

} 



- Timer m 
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- Issues fast forwarding on a voice message that is being played. The 
operation can only be issued when a voice message is being played. The 

— SN shall return the result immediately. 
~ Class 1 operation 

5 

GetDetailedMessagelnfo ::= OPERATION - Timer m — 

ARGUMENT 

GetDetailedMessagelnfoArg 
RESULT 

10 GetDetailedMessagelnfoResultArg 
ERRORS { 

Access Denied, 

UnknownMedia, 

UnknownMessage 
15 } 

- Get detailed information about a message, e.g. message header, length, 

— priority and message body. 

— Class 1 operation 

20 MailboxStatus : : = OPERATION - Timer m — 

ARGUMENT 

MailboxStatusArg 
RESULT 

MailboxStatusResultArg 
25 ERRORS { 

Access Denied, 
UnknownMedia 

} 

- Status enquiry regarding number of messages stored in a subscriber's 
30 - mailbox. 

~ Class 1 operation 



10 
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Pause ::= OPERATION - Timer m - 

ERRORS { 

IllegalOperation 
} 

- Issues pause on a voice message that is being played. The operation can 

- only be issued when a voice message is being played. An additional pause 

- operation resumes the playing of a voice message that has been paused. 

- The SN shall return the result immediately. 

- Class 1 operation 



PlayGreeting :: = OPERATION * - Timer m 

ERRORS { 

AccessDeniedToResource, 
SystemFailure 

15 } 

Requests the service node to play the current greeting. If there is no 

- speech connection established to the IMS, the SN shall establish a 

- speech connection. The result shall be returned when the speech 

- connection is allocated i.e. when the SN receives the "Alerting" indicator 
20 - from the network. The IMS shall accept the call when the result is returned. 

- The playing of the greeting is started when the answer message (ANM) is 

- detected by the SN. If there is a speech connection already established 

- the SN shall start the playing of the greeting immediately and return the 

- result immediately. 
25 - Class 1 operation 

PlayMessage : : = OPERATION - Timer m 

ARGUMENT 

PlayMessageArg 
30 ERRORS { 

AccessDeniedToResource, 
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SysteraFailure, 
NoMoreMessages , 
UnknownMessage 

} 

5 - Requests the SN to play the voice message(s) in the subscribers voice 

- mailbox. If there is no speech connection established to the IMS, the SN 
~ shall establish a speech connection. The result shall be returned when the 

— speech connection is allocated i.e. when the SN receives the "Alerting" 
indicator from the network. The IMS shall accept the call when the result is 

10 - returned. The playing of the message(s) is started when the answer 

— message (ANM) is detected by the SN. If there is a speech connection 

- already established, the SN shall start the playing of the message(s) 

— immediately and return the result immediately. 

- Class 1 operation 

15 

RecordGreeting : : = OPERATION - Timer m - 

ERRORS { 

AccessDeniedToResource, 
SystemFailure 
20 } 

— Requests the service node to record a new current greeting. If there is no 

— speech connection established to the IMS, the SN shall establish a 

- speech connection. The result shall be returned when the speech 

~ connection is allocated i.e. when the SN receives the "Alerting" indicator 
25 — from the network. The IMS shall accept the call when the result is returned. 

- The recording of the greeting is started when the answer message (ANM) 
-- is detected by the SN. If there is a speech connection already established 

- the SN shall start the recording of the greeting immediately and return the 

— result immediately. 
30 — Class 1 operation 
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ReleaseResource : : = OPERATION - Timer m 

ARGUMENT 

ReleaseResourceArg 
ERRORS { 

UnknownResource 

} 

- Requests the service node to release all resources that have been 

- allocated. due to message retrieval or record greeting, e.g. call legs and 

- signalling dialogues to IP's. 

- Class 1 operation 

RetrieveNewMessagelnfo ::= OPERATION - Timer m 

RESULT 

RetrieveNewMessagelnfoResultArg 
ERRORS { 

AccessDeniedToResource 

} 

- Retrieve the information about a new message. This operation is used 

- when the ITAP session is established with the service identity "New 

- Message Notification". The operation returns the new message notification 

- parameters. 

- Class 1 operation 

Rewind : : = OPERATION - Timer m 

ERRORS { 

IllegalOperation 

} 

- Issues rewind on a voice message that is being played: The operation can 

- only be issued when a voice message is being played. The SN shall 

- return the result immediately. 

- Class 1 operation 
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10 



SaveMessage ::= OPERATION 

ARGUMENT 

SaveMessageArg 

ERRORS { 

AccessDeniedToResource, 

UnknownMedia, 

UnknownMessage 

} 

— Saves a specified message. 

— Class 1 operation 



Timer m 



15 



20 



25 



30 



SendMessage :: = OPERATION ~ Timer m ~ 

ARGUMENT 

SendMessageArg 
ERRORS { 

AccessDeniedToResource, 

UnknownMedia, 

UnknownMessage, 

IllegalAddress 

} 

~ Send a message to a specified destination. The selected message that 
-- shall be forwarded is identified by the message identity together with the 
-- type of media. 
- Class 1 operation 



Stop ::= OPERATION 
ERRORS { 

IllegalOperation 

} 

-- Stops the playing a voice message. The SN shall return the result 
- immediately. 



- Timer m — 
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10 



- Class 1 operation 

PROFILE RELATED OPERATIONS 
AddEntryToScreeningList ::= OPERATION 
ARGUMENT 

AddEntryToScreeningListArg 
RESULT 

AddEntryToScreeningListResultArg 
ERRORS { 

AccessDeniedToResource 

} 

- Adds a new number to the white or black screening list 

- Class 1 operation 



Timer m 



15 



20 



DeleteCallLogEntry ::= OPERATION 

ARGUMENT 

DeleteCallLogEntry Arg 

ERRORS { 

AccessDeniedToResource , 
UnknownCallLog 

} 

— Deletes an entry in the call log. 

- Class 1 operation 



Timer m — 



25 DeleteEntrylnScreeningList ::= OPERATION 
ARGUMENT 

DeleteEntrylnScreeningListArg 
ERRORS { 

AccessDeniedToResource 
30 } 

— Deletes a number from a screening list 



Timer m 



~ Class 1 operation 
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EnquiryCallLog : : = OPERATION - Timer m 

ARGUMENT 

EnquiryCallLogArg 
RESULT 

EnquiryCallLogResultArg 
ERRORS { 

AccessDeniedToResource, 

UnknownCallLog 

} 

- Status enquiry regarding entries in the call log, e.g. timestamp and identity 

- of caller. The result indicates whether there are more status entries 
available in the SN or not. The remaining part is retrieved by additional 

- status enquires with the type of log assigned to more information. 

- Class 1 operation 

EnquiryScreeningList ; : = OPERATION - Timer m 

ARGUMENT 

EnquiryScreeningListArg 
RESULT 

EnquiryScreeningListResultArg 
ERRORS { 

AccessDeniedToResource 

} 

- Status enquiry regarding entries in the screening list, e.g. numbers that 

- shall be through connected. 

- Class 1 operation 



RetrieveActiveRoutingTable ::= OPERATION 
RESULT 



- Timer m 
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RetrieveActiveRoutingTableResultArg 
ERRORS { 

AccessDeniedToResource, 
UnknownRoutingTable 
5 } 

- Retrieve the identity and name of the predefined routing table that is 
-- currently active. 

~ Class 1 operation 

10 RetrieveBusyAndNoAnswerDest : : = OPERATION - Timer m - 

RESULT 

RetrieveBusyAndNoAnswerDestResultArg 
ERRORS { 

AccessDeniedToResource 

15 } 

- Retrieves the busy and no answer destinations. 

- Class 1 operation 

RetrievelmmediateDelivery : : = OPERATION - Timer m - 

20 ARGUMENT 

RetrievelmmediateDelivery Arg 
RESULT 

RetrievelmmediateDeliveryResultArg 
ERRORS { 

25 AccessDeniedToResource 

} 

- Retrieves the profile for immediate delivery of messages. 

- Class 1 operation 



30 



RetrieveLanguage ::= OPERATION 
RESULT 



- Timer m - 



-144- 



RetrieveLanguageResultArg 
ERRORS { 

AccessDeniedToResource 
} 

- Retrieves the language used for "plain old telephone service" (POTS) access. 

- Class 1 operation 



RetrieveNameOfRoutingTables ::= OPERATION 
RESULT 

10 RetrieveNameOfRoutingTablesResultArg 
ERRORS { 

AccessDeniedToResource 
} 

- Retrieve a list of names and identities of available routing tables 
15 Class 1 operation 



- Timer m - 



RetrieveNotificationType : : = OPERATION 
RESULT 

RetrieveNotificationTypeResultArg 
20 ERRORS { 

AccessDeniedToResource 

} 

- Retrieves the preferred notification type. 

- Class 1 operation 

25 

RetrieveRoutingList OPERATION 
ARGUMENT 

RetrieveRoutingListArg 
RESULT 

30 RetrieveRoutingListResultArg 
ERRORS { 



Timer m - 



- Timer m - 



-145- 



AccessDeniedToResource , 
UnknownRoutingList 

} 

- Retrieves the routing list 
~ Class 1 operation 



RetrieveRoutingTable ::= OPERATION 
ARGUMENT 

RetrieveRoutingTableArg 
10 RESULT 

RetrieveRoutingTableResultArg 
ERRORS { 

AccessDeniedToResource, 
UnknownRoutingTable 
15 } 

- Retrieves a routing table from the service node 

- Class 1 operation 



Timer m - 



RetrieveScreeningProfile ::= OPERATION 
20 RESULT 

RetrieveScreeningProfileResultArg 
ERRORS { 

AccessDeniedToResource 

} 

25 - Retrieves the screening profile 
- Class 1 operation 



- Tinier m - 



30 



RetrieveScreeningResons ::= OPERATION 
RESULT 

RetrieveScreeningResonsResultArg 
ERRORS { 



- Timer m 
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AccessDeniedToResource 
} 

— Retrieves the list of screening reasons. 
» Class 1 operation 

5 

RetrieveSearchTimes :: = OPERATION - Timer m - 

ARGUMENT 

RetrieveSearchTimesArg 
RESULT 

10 RetrieveSearchTimesResultArg 
ERRORS { 

AccessDeniedToResource, 
UnknownRoutingTable 

} 

15 — Retrieves the search times for a specific routing table. 
~ Glass 1 operation 

SetActiveRoutingTable ::= OPERATION - Timer m - 

ARGUMENT 
20 SetActiveRoutingTableArg 
ERRORS { 

AccessDeniedToResource, 

UnknownRoutingTable 

} 

25 - Change the active routing table to the predefined routing table specified 

- by the routing table id inparameter. 
-- Class 1 operation 



UpdateBusyAndNoAnswerDest : : = OPERATION 
30 Argument 

UpdateBusyAndNoAnswerDestArg 



~ Timer m - 
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ERRORS { 

AccessDeniedToResource 
} 

- Updates the busy and no answer destinations. 

- Class 1 operation 



UpdateEntrylnScreeningList ::= OPERATION 
ARGUMENT 

UpdateEntrylnScreeningListArg 
10 ERRORS { 

AccessDeniedToResource 

} 

~ Updates a entry in the screening list 
~ Class 1 operation 

15 

UpdateImmediateDelivery::= OPERATION 
ARGUMENT 

UpdatelmmediateDeliveryArg 
ERRORS { 

20 AccessDeniedToResource 

} 

« Updates the profile for immediate delivery of messages. 
- Class 1 operation 



- Timer m - 



- Timer m - 



25 UpdateLanguage : : = OPERATION 
ARGUMENT 

UpdateLanguageArg 
ERRORS { 

AccessDeniedToResource 
30 } 

- Update type of language used for POTS access. 



Timer m - 



— Class 1 operation 
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10 



UpdateNameOfRoutingTable ::= OPERATION 
ARGUMENT 

UpdateNameOfRoutingTableArg 
ERRORS { 

AccessDeniedToResource, 

UnknownRoutingTable 

} 

- Updates the name of a predefined routing table. 

- Class 1 operation 



- Timer m - 



UpdateNotificationType ::= OPERATION 
ARGUMENT 
15 UpdateNotificationTypeArg 
ERRORS { 

AccessDeniedToResource 

} 

- Updates the preferred notification type. 
20 - Class 1 operation 



- Timer m - 



UpdateRoutingTable ::= OPERATION 
ARGUMENT 

UpdateRoutingTableArg 
25 ERRORS { 

AccessDeniedToResource , 
UnknownRoutingTable 

} 

- Updates a routing table in the service node 
30 - Class 1 operation 



Timer m - 
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UpdateScreeningProfile ::= OPERATION 
ARGUMENT 

UpdateScreeningProfileArg 
ERRORS { 

AccessDeniedToResource 

} 

— Updates the screening profile 
. — Class 1 operation 



- Timer m - 



10 UpdateSearchTimes : : = OPERATION 
ARGUMENT 

UpdateSearchTimesArg 
ERRORS { 

AccessDeniedToResource, 
15 UnknownRoutingTable 

} 



- Timer m - 



20 



25 



30 



- Updates the search times for each alternative in a routing table 
~ Class 1 operation 

AUTHENTICATION OPERATIONS 
Authenticate ::= OPERATION 
ARGUMENT 

AuthenticateArg 
ERRORS { 

AuthenticationFailed, 

PINCodeBlocked 

} 

- Checks the entered PIN-Code 

- Class 1 operation 



- Timer m — 
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RetrieveAuthenticationStatus : : = OPERATION - Timer m - 

RESULT 

RetrieveAuthenticationStatusResultArg 
ERRORS { 

5 AccessDeniedToResource 

} 

- Retrieves the authentication status from the service node 
-Class 1 operation 

10 UpdateAuthenticationStatus : : = OPERATION - Timer m - 

ARGUMENT 

UpdateAuthenticationStatusResultArg 
ERRORS { 

AccessDeniedToResource 
15 } 

- Updates the authentication status in the service node 

— Class 1 operation 

UpdatePINCode ::= OPERATION - Timer m - 

20 ARGUMENT 

UpdatePINCodeArg 
ERRORS { 

AccessDeniedToResource, 
PINCodeFailure 
25 } 

— Update PIN-Code used to verify the identity of the service user. 
~ Class 1 operation 



30 



ERRORS 
FaxDetetced ::= ERROR 

— Fax detection has been successfully executed. The call has been routed to 
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~ the destination for fax calls and incoming call selection is terminated. 



HookOn ::= ERROR 

- A-part has performed hook on. 

5 

CallAnswered ERROR 

- The call has already been answered at another destination that has been 

- alerted in parallel. 

10 SystemFailure ::= ERROR 

- Call leg to was not through connected, e.g. due to congestion or 

- resource limitation. 

UnknownMessage ::= ERROR 
15 - Undefined message 

AccessDeniedToResource ::= ERROR 

- Access denied to a resource, e.g. voice mailbox or call log. 

20 UnknownMedia ::= ERROR 

- Undefined media 

UnknownStatus : : = ERROR 

- Undefined status 

25 

UnknownResource ::= ERROR 

- Undefined resource 

IllegalAddress ::= ERROR 
30 - Address invalid 
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NoMoreMessages ::= ERROR 

- No more messages in the mailbox. 

UnknownRoutingTable ::= ERROR 
5 - Undefined routing table 

UnknownCallLog ::= ERROR 
~ Undefined call log 

10 UnknownRoutingList ::= ERROR 

- Undefined routing list 

IllegalOperation : : = ERROR 

- Illegal operation. 

15 

AuthenticationFailed ::= ERROR 

- Illegal PIN-Code has been entered. 

PINCodeBlocked ::= ERROR 
20 — PIN-Code blocked, too many retries. 

NoAnswer ::= ERROR 

- No answer 

25 Busy ::= ERROR 

- Called party is busy 

NotReachable ::= ERROR 
~ Called party is not reachable 

30 
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ARGUMENTS DATA TYPES 
AddEntryToScreeningListArg ::= SEQUENCE { 

typeOfList [00] UnsignedByte, 

screeningAddress [01] Addresslnfo 

5 } 

- Type of list: 0 = White list, 1 = Black List 

- The PIN-Code or identity of caller that shall be added to the screening list. 

. AddEntryToScreeningListResultArg ::= SEQUENCE { 
10 index [00] UnsignedByte 

} 

- Index in the list where the new screening entry is stored. 

AuthenticateArg ::= SEQUENCE { 
15 pINCode [00] Number 

} 

- Entered PIN-Code. 

CancelMessageDeliveryArg::= SEQUENCE { 
20 messagelD [00] Longlnt, 

media [01] UnsignedByte 

} 

- Media: 1 = Fax mail, 2 = E-mail, 3 = SMS. 

25 DeleteCallLogEntryArg ::= SEQUENCE { 

typeOfLog [00] UnsignedByte, 

callLogEntry [01] UnsignedByte 

} 

- Type of call log: 0 = Incoming call log, 1 = Missed call log, 2 = Call back log 
30 - Call log entry is index in the call log. The index can be in the range of 1 to 

- 10. 
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DeleteMessageArg::= SEQUENCE { 

messagelD [00] SEQUENCE OF Longlnt OPTIONAL, 

media [01] SEQUENCE OF UnsignedByte 

OPTIONAL 
5 } 

- Media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS. The size of the 

- "SEQUENCE OF" parameters is in the range of SIZE(L.IO). The message id 
-- and media can be omitted if the operation is invoked during the playing of 

- voice message. Message id and media shall then be fetched by the SN from 
10 - the current message. 

DeleteEntrylnScreeningListArg ::= SEQUENCE { 

typeOfList [00] UnsignedByte, 

index [01] UnsignedByte 

15 } 

- Type of list: 0 = White list, 1 = Black List 

- Index: index of the entry in the screening list that shall be removed. 

EnquiryCallLogArg ::= SEQUENCE { 
20 typeOfLog [00] UnsignedByte 

} 

- Type of log: 0 = Incoming call log, 1 = Missed call log, 2 = Call back log, 3 

- get more information. 

25 EnquiryCallLogResultArg ::= SEQUENCE { 
moreToCome [00] BOOLEAN, 

timeStamp [01] SEQUENCE OF DateAndTime OPTIONAL, 
caller [02] SEQUENCE OF Addresslnfo OPTIONAL, 

answered [03] SEQUENCE OF Addresslnfo OPTIONAL 

30 } 

- The size of the "SEQUENCE OF" parameters is in the range of SIZE(L.IO) 
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EnquiryDeliveryLogArg ::= SEQUENCE { 

selectedMedia [00] UnsignedByte 

} 

~ Selected media: 1 = Fax mail, 2 = E-mail, 3 = SMS, 4 = all 

5 

EnquiryDeliveryLogResultArg ::= SEQUENCE { 

timeStamp [00] SEQUENCE OF DateAndTime OPTIONAL, 
status [01] SEQUENCE OF UnsignedByte OPTIONAL, 

messagelD [02] SEQUENCE OF Longlnt OPTIONAL, 
10 destination [03] SEQUENCE OF Addresslnfo OPTIONAL, 

media [04] SEQUENCE OF UnsignedByte OPTIONAL 

} 

- The size of the "SEQUENCE OF" parameters is in the range of 

~ SIZE(L.IO). The media parameter is only included if the selected media is 
15 - equal to "all". 

Enquiry MailboxArg ::= SEQUENCE { 

selectedMedia [00] UnsignedByte, 

selectedStatus [01] UnsignedByte 

20 } 

- Selected media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS, 4 = all 
~ Selected status: 0 = New, 1 = Old, 2 = Saved, 3 = All, 4 = More information 

EnquiryMailboxResultArg ::= SEQUENCE { 
25 morelnfoAvailable [00] BOOLEAN, 

timeStamp [01] SEQUENCE OF DateAndTime 

OPTIONAL, 

messagelD [02] SEQUENCE OF Longlnt OPTIONAL, 

originator [03] SEQUENCE OF Addresslnfo OPTIONAL, 

30 media [04] SEQUENCE OF UnsignedByte 

OPTIONAL, 



-156- 

status [05] SEQUENCE OF UnsignedByte 

OPTIONAL, 

messageHeader [06] SEQUENCE OF SMSString OPTIONAL 

} 

5 - The size of the "SEQUENCE OF" parameters, is in the range of 

- SIZE(1..5). The media parameter is only included if the selected media is 

- equal to "all". The status parameter is only included of the selected status 

- parameter is equal to "all". 

10 EnquiryScreeningListArg ::= SEQUENCE { 

typeOfList [00] UnsignedByte 

} 

- Type of list: 0 = White list, 1 = Black List 

15 EnquiryScreeningListResultArg ::.= SEQUENCE { 

index [00] SEQUENCE OF UnsignedByte OPTIONAL, 

screeningList [01] SEQUENCE OF Addresslnfo OPTIONAL 

} 

~ The size of the "SEQUENCE OF" parameters is in the range of SIZE(1. .25) 
20 - Index is in the range of (1.. 25) 

GetDetailedMessagelnfoArg ::= SEQUENCE { 

selectedMedia [00] UnsignedByte, 

messagelD [01] Longlnt 

25 } 

- Selected media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS, 4 = all 

GetDetailedMessagelnfoResuItArg ::= SEQUENCE { 

priority [00] UnsignedByte, 

30 length [01] Longlnt, 

messageHeader [02] SMSString OPTIONAL, 
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body [03] SMSString OPTIONAL, 

nameOfAttachments [04] SEQUENCE OF SMSString OPTIONAL 

} 

- Priority: 0 = low, 1 = normal, 2 = high 

5 — The length of the message depends on media: Voice messages (in 

- seconds), Fax messages (no of pages), E-mail (no of bytes), SMS (no of 

~ characters). The message body parameter is only applicable for E-mail. If 

- the message is longer than the size of SMSString, the message is 

- truncated. The size of the "SEQUENCE OF" parameters is in the range 
10 -- of SIZE(1..5). 

MailboxStatusArg ::= SEQUENCE { 

typeOfMedia [00] UnsignedByte 

} 

15 - Type of media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS, 4 = all 

MailboxStatusResultArg :: = SEQUENCE { 

numberOfVoiceMail [00] SEQUENCE OF UnsignedByte 

OPTIONAL, 

20 numberOfFaxMail [01] SEQUENCE OF UnsignedByte 

OPTIONAL, 

numberOfEmail [02] SEQUENCE OF UnsignedByte 

OPTIONAL, 

numberOfSMS [03] SEQUENCE OF UnsignedByte 
25 OPTIONAL 

} 

- Number of messages in the subscribers mailbox for the selected media. 

- If type of media is all in the request, all parameters are returned. If type of media 
is a specific media, the parameter for the requested media is returned, e.g. if type 

30 — of media is voice mail, number of voice mail will only be returned. 

The size of the SEQUENCE OF is always 4. The SEQUENCE OF contains 



-158- 

- the following information: 

Index 1 = Total no of messages, 
Index 2 = No of new messages, 
Index 3 = No of old messages, 
5 — Index 4 = No of saved messages, 

- If number of messages is 255, this indicates that there is at least 255 

- messages. 

PlayMessageArg:: = SEQUENCE { 
10 typeOfPlay [00] UnsignedByte, 

messagelD [01] Longlnt OPTIONAL 

} 

- TypeOfPlay: 0 = All, 1 = Specific, 2 = Repeat, 3 = Next 

- The SN shall start playing the voice message identified by the 

15 — message identity. If type of play is all, all messages shall be played in 
~ sequential order. If type of play is specific, the specified message shall 

- be played. If type of play is repeat, the current message shall be repeated. 

- If type of play is next, the next message shall be played. Repeat and next 

- can only be used when at least one message has been played. Message id 
20 - is not used for repeat and next. 

ReleaseResourceArg:: = SEQUENCE { 

typeOfResource [00] UnsignedByte 

} 

25 ~ Type of resource: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS, 4 = all 

RetrieveActiveRoutingTableResultArg : : = SEQUENCE { 

routingTablelD [00] UnsignedByte, 

routingTableName [01] SMSString 

30 } 

~ Active routing table routing table identifier can be in the range (1..5). 
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RetrieveAuthenticationStatusResultArg ::= SEQUENCE { 

authenticationActive [00] BOOLEAN 

} 

- Authentication status active (On/Off) 

5 

RetrieveBusyAndNoAnswerDestResultArg : : = SEQUENCE { 
busyDestination [00] Addresslnfo, 

noAnswerDestination [01] Addresslnfo 

} 

10 - Name and number shall be included in the address information, if the 

- information is available. If number shall not be presented for the service 

- user, e.g. if the busy destination is an operator defined destinations, the 

- name shall be included in the address information and the index in the 

- routing table shall be sent as address, e.g. #4. If the name is not available, 
15 — only the number shall be included. 

RetrieveImmediateDeliveryArg::= SEQUENCE { 

sourceMedia [00] UnsignedByte 

} 

20 -- Source media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS 
RetrieveImmediateDeliveryResultArg::= SEQUENCE { 



immediateDeliveryActive 


[00] 


BOOLEAN, 


autoCopyActive 


[01] 


BOOLEAN, 


immediateMedia 


[02] 


UnsignedByte OPTIONAL, 


immediateAddress 


[03] 


Addresslnfo OPTIONAL, 


autoCopyMedia 


[04] 


UnsignedByte OPTIONAL, 


autoCopyAddress 


[05] 


Addresslnfo OPTIONAL 



} 

30 - Name and number shall be included in the address information, if the 
- information is available. If number shall not be presented for the service 
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- user, e.g. if the destination is an operator defined destinations, the 

- name shall be included in the address information and the index in the 

- routing table shall be sent as address, e.g. #4. If the name is not available, 
~ only the number shall be included. 

5 - Immediate and auto copy media: 0 = Voice, 1 = Fax group3, 2 = Fax group4, 

- 3 = SMS, 4 = E-mail, 5 = Ermes, 6 = teletex, 7 = telex. 

RetrieveLanguageResultArg ::= SEQUENCE { 

language [00] UnsignedByte 

10 } 

- The value for the different languages complies to the values specified for 
~ the data type Language in the above sections under the heading "ITAP - 
OPERATIONS". 

15 RetrieveNameOfRoutingTablesResultArg ::= SEQUENCE { 

routingTablelD [00] SEQUENCE OF UnsignedByte, 

routingTableName [01] SEQUENCE OF SMSString 

} 

- List of name and identities of routing tables. The size of the "SEQUENCE 
20 - OF" parameters is in the range of SIZE(1..5). The routing table identifier 

- can be in the range (1..5). 

RetrieveNewMessageInfoResultArg::= SEQUENCE { 

numberOfNew [00] Longlnt, 

25 numberOfOld [01] Longlnt, 

numberOfSaved [02] Longlnt, 

media [03] UnsignedByte, 

originator [04] Addresslnfo, 

timeStamp [05] DateAndTime 



30 } 



Media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS 
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RetrieveNotificationTypeResultArg::= SEQUENCE { 

notificationStatus [00] BOOLEAN, 

typeOfNotification [01] UnsignedByte, 

notificationAddress [02] Addresslnfo OPTIONAL 

5 } 

- Type of notification: 0 = Dial out, 1 = Pager, 2 = SMS, 3 = Fax, 4 = E-mail 

- 5 = USSD, 6 = ITAP 

RetrieveRoutingListArg ::= SEQUENCE { 
10 typeOfList [00] UnsignedByte 

} 

- Type of list: 

- 0 = Routing table management, subscriber and operator defined 
~ destinations are returned. 

15 — 1 = Incoming Call selection Transfer Call, subscriber and operator defined 

- destinations are returned together with the latest transfer destinations. 

- 2 = Fax management, subscriber and operator defined destinations are returned. 

- 3 = E-mail management, default destinations for E-mails are returned. 

20 RetrieveRoutingListResultArg ::= SEQUENCE { 

destinations [00] SEQUENCE OF Addresslnfo OPTIONAL, 

latestDestinations [01] SEQUENCE OF Addresslnfo OPTIONAL 

} 

- The size of the "SEQUENCE OF" destination parameter is in the range of 
25 - SIZE(L.IO) and the latestDestinations is in the range of SIZE(1..2). Name 

- and number shall be included in the address information, if the information 
~ is available. If number shall not be presented for the service user, e.g. if the 

- destination is an operator defined destinations, the name parameter in the 
~ address information data type shall contain the name of the destination and 

30 ~ the number parameter shall contain the a hash mark followed by the index 

- in the routing list, e.g. #4. 
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- When the service user selects an entry from the routing list, the address 

- information from the routing list shall be sent to the SN. If it is an operator 

- defined destination, the SN shall use the routing list index in the number 

- parameter the to find the actual address. If the name is not available, only 
5 - the number shall be included. 

RetrieveRoutingTableArg ::= SEQUENCE { 

routingTablelD [00] UnsignedByte • 

} 

10 -- The routing table identifier can be in the range (1 . .5). 

RetrieveRoutingTableResultArg : : = SEQUENCE { 

callFirst [00] SEQUENCE OF Addresslnfo OPTIONAL, 

callSecond [01] SEQUENCE OF Addresslnfo OPTIONAL, 

15 callThird [02] SEQUENCE OF Addresslnfo OPTIONAL 

} 

-'- The size of the "SEQUENCE OF" parameters is in the range of SIZE(1..2). 
-- Name and number shall be included in the address information, if the 

- information is available. If number shall not be presented for the service 
20 ~ user, e.g. if the destination is an operator defined destinations, the 

- name shall be included in the address information and the index in the 

- routing table shall be sent as address, e.g. #4. If the name is not available, 
-- only the number shall be included. 

25 RetrieveScreeningProfileResultArg ::= SEQUENCE { 



situationScreeningActive 


[00] 


BOOLEAN, 


callerldScreeningActive 


[01] 


BOOLEAN, 


screeningReason 


[02] 


UnsignedByte, 


timeStamp 


[03] 


DateAndTime OPTIONAL, 


screeningDestination 


[04] 


Addresslnfo OPTIONAL 



} 
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- If screening is active the screening reason indicates the current screening 

- reason, e.g. meeting, vacation. If the screening is not active this parameter 

- indicates the last expired screening reason. Screening reason can be in the 

- range 1-10. 

5 

RetrieveScreeningReasonsResultArg : : = SEQUENCE { 

screeningReason [00] SEQUENCE OF SMSString OPTIONAL 

} 

~ Text associated with the screening reason, e.g. meeting, vacation. The size 
10 - of the "SEQUENCE OF" parameter is in the range of 1-10. 

RetrieveSearchTimesArg ::= SEQUENCE { 

routingTablelD [00] UnsignedByte 

• } 

15 — The routing table identifier can be in the range (1.. 5). 

RetrieveSearchTimesResultArg ::= SEQUENCE { 

searchTimeCallFirst [00] UnsignedByte, 

searchTimeCallSecond [01] UnsignedByte, 
20 searchTimeCallThird [02] UnsignedByte 

} 

- The search time can be in the range of 1 - 60 seconds. 

SaveMessageArg::= SEQUENCE { 
25 messagelD [00] Longlnt OPTIONAL, 

media [01] UnsignedByte OPTIONAL, 

tag [02] SMSString OPTIONAL 

} 

-- Media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS 
30 — The tag will be stored together with the message. The message id 

- and media can be omitted if the operation is invoked during the playing of 
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~ voice message. Message id and media shall then be fetched by the SN from 
- the current message. 



SendMessageArg::= SEQUENCE { 
5 messagelD [00] Longlnt, 

media [01] UnsignedByte, 

recipientMedia [02] UnsignedByte, 

recipientAddress [03] Addresslnfo . 

} 

10 ~ Media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS 

~ Recipient media: 0 = Voice, 1 = Fax group3, 2 = Fax group4, 3 = SMS, 

- 4 = E-mail, 5 = Ernies, 6 = teletex, 7 = telex. 

SetActiveRoutingTableArg ::= SEQUENCE { 
15 routingTablelD [00] UnsignedByte 

} 

~ Sets active routing Table. The routing table identifier can be in the range 
-(1..5). 

20 SetUpCallArg: : = SEQUENCE { 

bNumber [00] Addresslnfo OPTIONAL 

} 

- Number that the call shall be established to. The bnumber can be omitted if 

- the operation is invoked during the playing of voice messages. The SN shall 
25 - then fetch the number from the current message. 

TransferCallArg ::= SEQUENCE { 

transferToNumber [00] Addresslnfo 

} 

30 - Number to which the call will be transferred. If the transfer destination is a 

- entry from the routing list, the complete address information from the 
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~ routing list shall be sent. If the transfer destination is from the local address 

- book or a manually entered number, only the number shall be sent to the SN. 

UpdateAuthenticationStatusArg ::= SEQUENCE { 
5 authenticationActive [00] BOOLEAN 

} 

- Authentication status active (On/Off) 

UpdateBusyAndNoAnswerDestArg SEQUENCE { 
10 busyDestination [00] Addresslnfo, 

noAnswerDestination [01] Addresslnfo 

} 

- If the address information are entries from the routing list, the complete 

- address information from the routing list shall be sent. If the address 

15 - information are from the local address book or manually entered numbers, 

- only the numbers shall be sent to the SN. 

UpdateEntrylnScreeningListArg ::= SEQUENCE { 

typeOfList [00] UnsignedByte, 

index [01] UnsignedByte, 

screeningAddress [02] Addresslnfo 

} 

- Type of list: 0 = White list, 1 = Black List 

- Index: Index of the entry in the screening list that shall be updated. 

- New PIN-Code or Identity of caller that shall be updated in the screening list. 

UpdateImmediateDeliveryArg::= SEQUENCE { 

sourceMedia [00] UnsignedByte, 

immediateDelivery Active [01] BOOLEAN, 

30 autoCopyActive [02] BOOLEAN, 

immediateMedia [03] UnsignedByte OPTIONAL, 



20 



25 
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immediateAddress [04] Addresslnfo OPTIONAL, 

autoCopyMedia [05] UnsignedByte OPTIONAL, 

autoCopy Address [06] Addresslnfo OPTIONAL 

} 

5 — If the address information are entries from the routing list, the complete 

— address information from the routing list shall be sent. If the address 

— information are from the local address book or manually entered numbers, 

- only the numbers shall be sent to the SN. 

Source media: 0 = Voice mail, 1 = Fax mail, 2 = E-mail, 3 = SMS 
10 — Immediate and auto copy media: 0 = Voice, 1 = Fax group3, 2 = Fax 

- group4, 3 = SMS, 4 = E-mail, 5 = Ermes, 6 = teletex, 7 = telex. 

UpdateLanguageArg ::= SEQUENCE { 

language [00] UnsignedByte 

15 } 

~ The value for the different languages complies to the values specified for 
~ the data type Language in the above sections under the heading "ITAP - 
OPERATIONS". 

20 UpdateNameOfRoutingTableArg::= SEQUENCE { 

routingTablelD [00] UnsignedByte, 

routingTableName [01] SMSString 

} 

~ Updates the name of a routing table. The routing table identifier can be in 
25 -- the range (1.. 5). 

UpdateNotificationTypeArg::= SEQUENCE { 

notificationStatus [00] BOOLEAN, 

typeOfNotification [01] UnsignedByte, 

30 notificationAddress [02] Addresslnfo OPTIONAL 

} 
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— Type of notification: 0 = Dial out, 1 = Pager, 2 = SMS, 3 = Fax, 4 = E-mail 

— 5 - USSD, 6 = ITAP 

UpdatePINCodeArg ::= SEQUENCE { 
5 oldPINCode [00] Number, 

newPINCode [01] Number 

} 

— The old PIN code is compared with the PIN code stored in the profile 

— before the PIN code is updated. 

10 

UpdateRoutingTableArg ::= SEQUENCE { 

routingTablelD [00] UnsignedByte, 

callFirst [01] SEQUENCE OF Addresslnfo OPTIONAL, 

callSecond [02] SEQUENCE OF Addresslnfo OPTIONAL, 

15 callThird [03] SEQUENCE OF Addresslnfo OPTIONAL 

} 

— The routing table identifier can be in the range (1..5). The size of the 

— "SEQUENCE OF" parameters is in the range of SIZE(1..2). 

— If the address information are entries from the routing list, the complete 
20 — address information from the routing list shall be sent. If the address 

— information are from the local address book or manually entered numbers, 

— only the numbers shall be sent to the SN. 

UpdateScreeningProfileArg ::= SEQUENCE { 



situationScreeningActive 


[00] 


BOOLEAN, 


callerldScreeningActive 


[01] 


BOOLEAN, 


screeningReason 


[02] 


UnsignedByte, 


timeStamp 


[03] 


DateAndTime OPTIONAL, 


screeningDestination 


[04] 


Addresslnfo OPTIONAL 



30 } 

— The screening reason indicates the current screening reason, e.g. meeting, 
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- vacation. Screening reason can be in the range 1 - 10. 



UpdateSearchTimesArg ::= SEQUENCE { 

routingTablelD [00] UnsignedByte, 

5 searchTimeCallFirst [01] UnsignedByte, 

searchTimeCallSecond [02] UnsignedByte, 
searchTimeCallThird [03] UnsignedByte 

} 

~ The routing table identifier can be in the range (L.5). Search times can be 
10 — in the range of 1 - 60 seconds. 

OPERATION CODES 
Call related operations 

acceptCall AcceptCall ::= 10 

15 callBack CallBack : : = 1 1 
holdCall HoldCall 12 
rejectCall RejectCall 13 

setUpCall SetUpCall : : = 14 

transferCall TransferCall : : = 15 

20 enquiryCallSetUpStatus EnquiryCallSetUpStatus ::= 16 

Message related operations 

cancelMessageDelivery CancelMessageDelivery : : = 32 

deleteMessage DeleteMessage : : = 33 

25 enquiryDeliveryLog EnquiryDeliveryLog : : = 34 

enquiry Mailbox Enquiry Mailbox ::= 35 

fastForwarding FastForwarding : : = 36 

getDetailedMessagelnfo GetDetailedMessagelnfo : : = 37 

mailboxStatus MailboxStatus : : = 38 

30 pause Pause : : = 39 

playGreeting PlayGreeting : : = 40 
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playMessage PlayMessage 
recordGreeting RecordGreeting 
releaseResource ReleaseResource 
retrieveNewMessagelnfo RetrieveNewMessagelnfo 
5 rewind Rewind 

saveMessage SaveMessage 
sendMessage SendMessage 
stop Stop 

10 Profile related operations 

addEntryToScreeningList AddEntryToScreeningList 
deleteCallLogEntry DeleteCallLogEntry 
deleteEntrylnScreeningList DeleteEntrylnScreeningList 
enquiryCallLog EnquiryCallLog 

15 enquiryScreeningList EnquiryScreeningList 

retrieveActiveRoutingTable RetrieveActiveRoutingTable 
retrieveBusyAndNoAnswerDest RetrieveBusyAndNoAnswerDest 
retrievelmmediateDelivery RetrievelmmediateDelivery 
retrieveLanguage RetrieveLanguage 

20 retrieveNameOfRoutingTables RetrieveNameOfRoutingTables 
retrieveNotificationType RetrieveNotificationType 
retrieveRoutingList RetrieveRoutingList 
retrieveRoutingTable RetrieveRoutingTable 
retrieveScreeningProfile RetrieveScreeningProfile 

25 retrieveScreeningResons RetrieveScreeningResons 
retrieveSearchTimes RetrieveSearchTimes 
setActiveRoutingTable SetActiveRoutingTable 
updateBusyAndNoAnswerDest UpdateBusyAndNoAnswerDest 
updateEntrylnScreeningList UpdateEntrylnScreeningList 

30 updatelmmediateDelivery UpdatelmmediateDelivery 
updateLanguage UpdateLanguage 



-170- 



updateNameOfRoutingTable UpdateNameOfRoutingTable 
updateNotificationType UpdateNotificationType 
updateRoutingTable UpdateRoutingTable 
updateScreeningProfile UpdateScreeningProfile 
5 updateSearchTimes UpdateSearchTimes 



Authentication operations 

authenticate Authenticate : : = 120 

retrieve AuthenticationStatus< Retrieve AuthenticationStatus :: = 121 

10 updateAuthenticationStatus UpdateAuthenticationStatus : : = 122 

updatePINCode UpdatePINCode : : = 123 

ERROR CODES 

faxdetected FaxDetetced : : = 20 

15 hookOnHookOn ::= 21 

callAnswered CallAnswered ::= 22 

systemFailure SystemFailure : : = 23 

unknownMessage UnknownMessage : : = 24 

accessDeniedToResource AccessDeniedToResource : : = 25 

20 unknownMedia UnknownMedia , . : : = 26 

unknownStatus UnknownStatus : : = 27 

unknownResource UnknownResource : : = 28 

illegalAddress IllegalAddress : : = 29 

noMoreMessages NoMoreMessages : : = 30 

25 unknownRoutingTable UnknownRoutingTable ::= 31 

unknownCallLog UnknownCallLog : : = 32 

unknownRoutingList UnknownRoutingList ::= 33 

IllegalOperation IllegalOperation : : = 34 

authenticationFailed AuthenticationFailed : : = 35 

30 pINCodeBlocked PINCodeBlocked : : = 36 

noAnswer NoAnswer : : = 37 



= 85 
= 86 
- 87 
= 88 
= 89 
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busy Busy ::= 38 

notReachable NotReachable : : = 39 

END 

5 A number of exemplary ITAP scenarios will now be described with 

reference to FIGS. 52 through 64. 

Referring first to FIGS. 52 through 57, these figures illustrate scenarios 
relating to incoming call selection. FIG. 52 shows an incoming call selection with the 
call being accepted. The IMS 1401 starts a new session upon reception of a new call 

10 indication (step 5201) in the IMS with the Bind operation (step 5203). The SN 1409 
responds with the caller name and number (step 5205). In this example, the IMS 
application version is equal to the application version in the SN 1409 and the start 
image description is available in the cache memory. Since the traffic channel is 
already allocated, the speech connection will be established immediately when the call 

15 is accepted locally in the IMS 1401 (step 5207). The new session is closed by 
sending an Unbind operation (step 5209). 

FIG. 53 shows a scenario relating to incoming call selection with the 
call being rejected. The IMS 1401 starts a new session upon reception of a new call 
indication in the IMS 1401 (step 5301) with the Bind operation (step 5303). The SN 

20 1409 responds with the caller name and number (step 5305). In this case, the IMS 
application version is equal to the application version in the service node and the start 
image description is available in the cache memory. The call is rejected and the 
signalling resource is released (step 5307). 

FIG. 54 depicts a scenario relating to incoming call selection with the 

25 call being transferred. The IMS 1401 starts a new session upon reception of a new 
call indication in the IMS 1401 (step 5401) with the Bind operation (step 5403). The 
service node 1409 responds with the caller name and number (step 5405). In this 
case, the IMS application version is equal to the application version in the service 
node 1409 and the start image description is available in the cache memory. The call 

30 is transferred (step 5407) and the predefined destinations related to call transfer are 
updated. 
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FIG. 55 shows a scenario relating to incoming call selection with a call 
hold being invoked. The IMS 1401 starts a new session upon reception of a new call 
indication in the IMS (step 5501) with the Bind operation (step 5503). The service 
node 1409 responds with the caller name and number (step 5505). In this case, the 
5 IMS application version is equal to the application version in the service node 1409 
and the start image description is available in the cache memory. The service user 
requests the caller to hold the line (step 5507) and the call is accepted after a while 
. 5509). 

FIG. 56 shows a scenario relating to incoming call selection with a call 

10 back being invoked. The IMS 1401 starts a new session upon reception of a new call 
indication in the IMS 1401 (step 5601) with the Bind operation (step 5603). The 
service node 1409 responds with the caller name and number (step 5605). In this 
case, the IMS 1401 application version is equal to the application version in the 
service node 1409 and the start image description is available in the cache memory. 

15 The service user requests the personal access application to play a predefined message 
to the caller (step 5607). 

The scenario shown in FIG. 57 relates to incoming call selection when 
an ITAP session is already in progress. An ITAP session between the service node 
and the IMS 1401 is already in progress (5701). The IMS 1401 starts a new session 

20 upon reception of a new call indication in the IMS 1401 (step 5703) with the Bind 
operation (step 5705). The service node 1409 responds with the caller name and 
number (step 5707). Since the call leg is already established to the IMS 1401, accept 
call is only executed in the IMS 1401. The service node 1409 detects that the call is 
accepted by monitoring the answer event. The new session is closed by sending an 

25 Unbind operation (step 5709). The service node 1409 resumes the old session by 
sending an empty USSD request operation to the IMS 1401 (step 5711). 

Mailbox-related services will now be described with reference to FIGS. 
58 through 61. In FIG. 58, the service user initiates an ITAP session (step 5801). 
After issuing a MailboxStatus invoke (step 5803), the service user selects to enquiry 

30 the voice mailbox about new messages (step 5805). 
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Referring now to FIG. 59, the service user has established an ITAP 
session and enquired the voice mailbox. The service user selects to play the voice 
messages (step 5901). Once the speech connection is allocated to the IMS 1401 (step 
5903), the result is returned to the IMS 1401 (step 5905). The playing of the voice 
5 messages is controlled by DTMF signalling (step 5907). When the service user 
selects to end the voice mail session, a ReleaseResource operation is sent to the SN 
1409 (step 5909). 

Turning now to FIG. 60, the service user has established an ITAP 
session and enquired the voice mailbox or any of the call logs. The service user 
10 selects to call the originator of the voice message or the number stated in the call log 
(step 6001). Call setup proceeds as previously described in this document. 

Referring now to FIG. 61, the IMS 1401 initiates an ITAP session and 
application version is equal in the service node 1409 and in the IMS 1401. The image 
descriptions are available in the cache. After issuing an EnquiryMailbox invoke (step 
15 6101) and receiving the result (step 6103), the IMS 1401 issues a SendMessage 

invokd (step 6105) to receive a fax. In response, one new fax message is forwarded 
(step 6107). 

Updating of the routing table will now be described with reference to 
FIGS. 62 and 63. Referring first to FIG. 62, one of the routing tables is retrieved 
20 from the service node 1409 and displayed for the service user on the IMS 1401 (steps 
6201, 6203, 6205 and 6207). The service user modifies the routing table and the 
tables is saved in the service node (steps 6209 and 6211). 

Referring now to FIG. 63, the service node 1409 is enquired about 
available routing tables (steps 6301 and 6303). The service user selects one routing 
25 table and that routing table becomes active by means of the IMS 1401 issuing a 
SetActive RoutingTable invoke (step 6305). 

New message notification using ITAP will now be described with 
reference to FIG. 64. Normally SMS is used as the notification medium. However 
by using ITAP/USSD as a notification medium for new messages, the service user can 
30 immediately enquire the mailbox in the already established ITAP session. The SN 
1409 alerts the IMS 1401 about a new message (step 6401). In this case, the IMS 
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application version is equal to the application version in the service node 1409 and the 
start image description is available in the cache memory. The information about the 
new message is fetched from the SN (steps 6403 and 6405). The service user 
proceeds by enquiring the mailbox (steps 6407 and 6409). The session continues as 
5 described in FIGS. 58 through 61 and the accompanying text. 

The invention has been described with reference to a particular 
embodiment. However, it will be readily apparent to those skilled in the art that it is 
possible to embody the invention in specific forms other than those of the preferred 
embodiment described above. This may be done without departing from the spirit of 
10 the invention. The preferred embodiment is merely illustrative and should not be 
considered restrictive in any way. The scope of the invention is given by the 
appended claims, rather than the preceding description, and all variations and 
equivalents which fall within the range of the claims are intended to be embraced 
therein. 
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WHAT IS CLAIMED IS: 

1 . In a communications system that includes a service node connected to 
an intelligent terminal by means of a limited bandwidth communications means, a 

5 method of providing a service to a user of the intelligent terminal, the method 
comprising the steps of: 

in the service node, analyzing an event to determine a primitive; 
using the limited bandwidth communications means to send a message 
to the intelligent terminal, wherein the message instructs the intelligent terminal to 
10 execute a routine corresponding to the primitive; and 

in the intelligent terminal, responding to the message by executing the 
routine corresponding to the primitive, 

wherein the step of sending the message to the intelligent terminal is 
performed independently of whether a speech connection is established on the limited 
15 bandwidth communications means. 

2. The method of claim 1, wherein: 

the message further includes parameters; and 

the step of executing the routine corresponding to the primitive includes 
20 using the received parameters. 

3. The method of claim 1, wherein the step of executing the routine 
includes the step of presenting information to the user of the intelligent terminal. 

25 4. The method of claim 1, wherein the step of executing the routine 

includes the step of changing a state of the intelligent terminal. 

5. The method of claim 1, wherein the event is receipt of a message from 

the intelligent terminal, the message indicating that the user has activated a man- 
30 machine interface of the intelligent terminal. 
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6. The method of claim 1, wherein the event is detection by the service 
node of an occurrence of something that affects the intelligent terminal. 

7. The method of claim 6, wherein the occurrence is an incoming call 
5 directed at the intelligent terminal. 

8. The method of claim 1, wherein the step of, in the intelligent terminal, 
responding to the message by executing the routine corresponding to the primitive 
comprises the steps of: 

10 in the intelligent terminal, determining that execution of the routine 

requires the presence of a state table that is not presently stored in the intelligent 
terminal; 

using the limited bandwidth communications means to send a message 
from the intelligent terminal to the service node, wherein the message requests the 
15 state table; 

using the limited bandwidth communications means to send the 
requested state table from the service node to the intelligent terminal; and 

in the intelligent terminal, using the received state table to execute the 

routine. 

20 

9. The method of claim 1, further comprising the step of, in the intelligent 
terminal, performing menu-handling input and output functions between the intelligent 
terminal and the user without communicating with the service node. 

25 10. The method of claim 1, further comprising the step of controlling 

intelligent terminal user input and output functions in accordance with a man-machine 
interface paradigm that is independent of the service being provided. 



30 



11. . In a communications system that includes a service node connected to 

an intelligent terminal by means of a limited bandwidth communications means, a 
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raethod of providing a service to a user of the intelligent terminal, the method 
comprising the steps of: 

in the intelligent terminal, analyzing an event to determine an action to 

be taken; 

using the limited bandwidth communications means to send an operation 
to the service node, wherein the operation corresponds to the action to be taken and 
instructs the service node to execute a routine corresponding to the operation; and 

. in the service node, performing the action corresponding to the 
operation, and returning a result of the operation to the intelligent terminal via the 
limited bandwidth communications means, 

wherein the step of sending the operation to the service node is 
performed independently of whether a speech connection is established on the limited 
bandwidth communications means. 

12. The method of claim 11, further comprising the step of: 

in the intelligent terminal, initiating a first session with the service node 
via the limited bandwidth communications means. 

13. The method of claim 12, wherein the step of, in the intelligent 
terminal, initiating a first session with the service node via the limited bandwidth 
communications means is performed in response to detection of an incoming call at 
the intelligent terminal. 

14. The method of claim 12, wherein the step of, in the intelligent 
terminal, initiating a first session with the service node via the limited bandwidth 
communications means is performed in response to a detection that the user has 
activated a man-machine interface of the intelligent terminal. 

15. The method of claim 11, further comprising the step of: 

in the service node, initiating a first session with the intelligent terminal 
via the limited bandwidth communications means. 
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16. The method of claim 15, wherein the step of, in the service node, 
initiating a first session with the intelligent terminal via the limited bandwidth 
communications means is performed in response to detection of an event directed at 
the intelligent terminal. 

5 

17. The method of claim 12, wherein the step of initiating the first session 
with the service node comprises the step of negotiating between the intelligent 
terminal and the service node to ensure that resources that are to be used by the 
intelligent terminal and the service node are consistent with respect to one another. 

10 

18. The method of claim 12, wherein the step of initiating the first session 
with the service node includes the step of indicating a type of coding that is to be used 
in communications between the intelligent terminal and the service node. 

15 19. The method of claim 18, wherein the type of coding is Basic Encoding 

Rules. 

20. The method of claim 18, wherein the type of coding is Packed 
Encoding Rules. 

20 

21. The method of claim 12, further comprising the step of initiating a 
second session between the intelligent terminal and the service node while maintaining 
the first session. 

25 22. The method of claim 11, further comprising the step of sending an 

image description from the service node to the intelligent terminal, wherein the image 
description defines operations that are to be performed by the intelligent terminal. 
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23. The method of claim 11, further comprising the step of sending an 

image description from the service node to the intelligent terminal, wherein the image 
description defines information to be supplied to the user of the intelligent terminal. 
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24. The method of claim 11, further comprising the step of sending an 
image description from the service node to the intelligent terminal, wherein the image 
description defines one or more steps to be performed by the intelligent terminal in 
response to detection of an event in the intelligent terminal. 

5 . 

25. The method of claim 24, wherein the image description further defines 
information to be supplied to the user of the intelligent terminal. 

26. The method of claim 11, further comprising the step of sending an 

10 image description from the service node to the intelligent terminal, wherein the image 
description defines one or more local terminal functions to be performed by the 
intelligent terminal in response to detection of an event in the intelligent terminal. 

27. The method of claim 11, wherein the step of using the limited 

15 bandwidth communications means to send an operation to the service node comprises 
mapping the operation onto an "Unstructured Supplementary Services Data" protocol 
data unit. 

28. The method of claim 11, wherein the step of using the limited 

20 bandwidth communications means to send an operation to the service node comprises 
mapping the operation onto two or more "Unstructured Supplementary Services Data" 
protocol data units. 

29. The method of claim 11, wherein the step of using the limited 

25 bandwidth communications means to send an operation to the service node comprises 
mapping the operation onto a Short Message Service protocol data unit. 

30. The method of claim 1 1 , wherein the step of using the limited 
bandwidth communications means to send an operation to the service node comprises 

30 mapping the operation onto a protocol data unit of a lower layer protocol. 
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31. The method of claim 30, further comprising the step of sending an 

operation from the intelligent terminal to the service node in order to avoid an 
occurrence of a timeout associated with a service provider of the lower layer protocol. 

5 32. The method of claim 30, wherein the operation is associated with an 

application protocol service provider, and further comprising the steps of terminating 
and reestablishing a session of the application protocol service in order to avoid an 
occurrence of a timeout associated with a service provider of the lower layer protocol. 

10 33. The method of claim 11, wherein the step of using the limited 

bandwidth communications means to send an operation to the service node comprises 
mapping the operation onto two or more protocol data units of a lower layer protocol. 

34. The method of claim 11, further comprising the steps of: 

15 performing a local service function in the intelligent terminal without 

requesting assistance from the service node. 

35. The method of claim 11, wherein the step, of, in the service node, 
returning the result of the operation to the intelligent terminal via the limited 

20 bandwidth communications means comprises mapping the result onto two or more 
protocol data units of a lower layer protocol. 

36. An apparatus for providing a service to a user, comprising: 
an intelligent terminal; 

25 a service node; and 

a communications means for transporting information between the 
intelligent terminal and the service node, 

wherein the intelligent terminal comprises: 

a terminal bearer service provider, coupled to the 
30 communications means, for exchanging protocol data units with a service node bearer 
service provider located in the service node; 
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a terminal application protocol service provider that uses the 
terminal bearer service provider to establish a first session with a service node 
application protocol service provider located in the service node and for exchanging 
operations with the service node application protocol service provider without 
5 requiring that the terminal bearer service provider establish a speech connection on 
the communications means; and 

a terminal service application for providing a local service to the 
user, and for using the terminal application protocol. service provider to invoke a 
remote user service that is to be performed by a service node service application, 
10 and wherein the service node comprises: 

the service node bearer service provider, coupled to the 
communications means, for exchanging protocol data units with the terminal bearer 
service provider located in the intelligent terminal; 

the service node application protocol service provider that uses 
15 the service node bearer service provider to establish the first session with the terminal 
application protocol service provider located in the intelligent terminal and for 
exchanging operations with the terminal application protocol service provider without 
requiring that the service node bearer service provider establish a speech connection 
on the communications means; and 
20 the service node service application for performing the remote 

service, and for using the service node application protocol service provider to supply 
results of the remote service to the terminal service application. 

37. The apparatus of claim 36, wherein the terminal service application is 

25 an image description interpreter. 



38. The apparatus of claim 37, wherein the service node application 

protocol service provider comprises means for sending an image description to the 
terminal application protocol service provider, 
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and wherein the terminal application protocol service provider 
comprises means for receiving the image description and for supplying the image 
description to the image description interpreter. 

5 39. The apparatus of claim 38, wherein the image description defines 

operations that are to be performed by the intelligent terminal. 

40. The apparatus of claim 38, wherein the image description defines 
information to be supplied to the user of the intelligent terminal. 

10 

41. The apparatus of claim 38, wherein the image description defines one 
or more steps to be performed by the intelligent terminal in response to detection of 
an event in the intelligent terminal. 

15 42. The apparatus of claim 41, wherein the image description further 

defines information to be supplied to the user of the intelligent terminal. 

43. The apparatus of claim 38, wherein the image description defines one 
or more local terminal functions to be performed by the intelligent terminal in 

20 response to detection of an event in the intelligent terminal. 

44. The apparatus of claim 36, wherein the terminal application protocol 
service provider establishes the first session in response to detection of an incoming 
call at the intelligent terminal. 

25 

45. The apparatus of claim 36, wherein the terminal application protocol 
service provider establishes the first session in response to a detection that the user 
has activated a man-machine interface of the intelligent terminal. 
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46. The apparatus of claim 36, wherein the service node application 

protocol service provider establishes the first session with the terminal application 
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protocol service provider in response to detection of an event directed at the 
intelligent terminal. 



47. The apparatus of claim 36, wherein the terminal application protocol 
5 service provider comprises means for negotiating with the service node application 

protocol service provider to ensure that resources that are to be used by the intelligent 
terminal and the service node are consistent with respect to one another. 

48. The apparatus of claim 36, wherein the terminal application protocol 
10 service provider includes means for indicating to the service node application protocol 

service provider a type of coding that is to be used in communications between the 
intelligent terminal and the service node. 

49. The apparatus of claim 48, wherein the type of coding is Basic 
15 Encoding Rules. 

50. The apparatus of claim 48, wherein the type of coding is Packed 
Encoding Rules. 

20 51 . The apparatus of claim 36, wherein the terminal application protocol 

service provider further includes means for establishing a second session with the 
service node application protocol service provider while maintaining the first session. 

52. The apparatus of claim 36, wherein the terminal application protocol 
25 service provider uses the terminal bearer service provider by mapping an operation 

onto two or more protocol data units. 

53. The apparatus of claim 52, wherein the terminal application protocol 
service provider includes means for sending an operation from the intelligent terminal 

30 to the service node in order to avoid an occurrence of a timeout associated with the 
terminal and service node bearer service providers. 
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54. The apparatus of claim 52, wherein the terminal application protocol 
service provider includes means for terminating and reestablishing the first session in 
order to avoid an occurrence of a timeout associated with the terminal and service 
node bearer service providers. 

5 

55. The apparatus of claim 36, wherein the service node application 
protocol service provider uses the service node bearer service provider by mapping a 
response onto two or more protocol data units. 

10 56. An intelligent terminal, comprising: 

coupling means for coupling the intelligent terminal to a 
communications means for transporting information between the intelligent terminal 
and a service node; 

a terminal bearer service provider, connected to the coupling means, 
15 for exchanging protocol data units with a service node bearer service provider located 
in the service node; 

a terminal application protocol service provider that uses the terminal 
bearer service provider to establish a first session with a service node application 
protocol service provider located in the service node and for exchanging operations 
20 with the service node application protocol service provider without requiring that the 
terminal bearer service provider establish a speech connection on the communications 
means; and 

a terminal service application for providing a local service to the user, 
and for using the terminal application protocol service provider to invoke a remote 
25 user service that is to be performed by a service node service application. 

57. The intelligent terminal of claim 56, wherein the terminal service 

application is an image description interpreter. 

30 58. The intelligent terminal of claim 57, wherein the terminal application 

protocol service provider comprises means for receiving an image description from 
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the service node application protocol service provider and for supplying the image 
description to the image description interpreter. 

59. The intelligent terminal of claim 58, wherein the image description 
5 defines operations that are to be performed by the intelligent terminal. 

60. The intelligent terminal of claim 58, wherein the image description 
defines information to be supplied to a user of the intelligent terminal. 

10 61. The intelligent terminal of claim 58, wherein the image description 

defines one or more steps to be performed by the intelligent terminal in response to 
detection of an event in the intelligent terminal. 

62. The intelligent terminal of claim 61, wherein the image description 
15 further defines information to be supplied to a user of the intelligent terminal. 

63. The intelligent terminal of claim 58, wherein the image description 
defines one or more local terminal functions to be performed by the intelligent 
terminal in response to detection of an event in the intelligent terminal. 

20 

64. The intelligent terminal of claim 56, wherein the terminal application 
protocol service provider establishes the first session in response to detection of an 
incoming call at the intelligent terminal. 

25 65. The intelligent terminal of claim 56, wherein the terminal application 

protocol service provider establishes the first session in response to a detection that 
the user has activated a man-machine interface of the intelligent terminal. 
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66. The intelligent terminal of claim 56, wherein the terminal application 

protocol service provider comprises means for negotiating with the service node 
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application protocol service provider to ensure that resources that are to be used by 
the intelligent terminal and the service node are consistent with respect to one another. 



67. The intelligent terminal of claim 56, wherein the terminal application 

5 protocol service provider includes means for indicating to the service node application 
protocol service provider a type of coding that is to be used in communications 
between the intelligent terminal and the service node. 

68. The intelligent terminal of claim 67, wherein the type of coding is 
10 Basic Encoding Rules. 

69. The intelligent terminal of claim 67, wherein the type of coding is 
Packed Encoding Rules. 

15 70. The intelligent terminal of claim 56, wherein the terminal application 

protocol service provider further includes means for establishing a second session with 
the service node application protocol service provider while maintaining the first 
session. 

20 71. The intelligent terminal of claim 56, wherein the terminal application 

protocol service provider uses the terminal bearer service provider by mapping an 
operation onto two or more protocol data units. 

72. The intelligent terminal of claim 71, wherein the terminal application 
25 protocol service provider includes means for sending an operation from the intelligent 

terminal to the service node in order to avoid an occurrence of a timeout associated 
with the terminal and service node bearer service providers. 

73. The intelligent terminal of claim 71, wherein the terminal application 
30 protocol service provider includes means for terminating and reestablishing the first 
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session in order to avoid an occurrence of a timeout associated with the terminal and 
service node bearer service providers. 




FIG. 1A 

INTERACTING SOFTWARE LINK 




FIG. 1B 

SUBSTITUTE SHEET (RULE 26) 



SERVICE NODE 



FIXED ANALOGUE 
TELEPHONE 




INTERACTING SOFTWARE LINK 
MODEM RESOURCE LINK 





/□□□\ 
/ odd N 



v 




119 
J 
121 

•123 



FIXED NETWORK 




DIFFERENT OR SAME NETWORK 



125 



FIG. 1C 




SUBSTITUTE SHEET (RULE 26) 



SERVICE NODE 



INTERACTING SOFTWARE 



MODEM RESOURCE 





CELLULAR 
TELEPHONE 



FIG. 2A 



SERVICE NODE 



CELLULAR 
TELEPHONE 



DIGITAL 
SIGNALLING 




RADIO 
BASE 
STATION 



FIG. 2B 



SUBSTITUTE SHEET (RULE 26) 




SUBSTITUTE SHEET (RULE 26) 



UJ 



CO 
LU 



LU 
Q 
O 
O 

LU 
LU O 

q:> 

CO LU 
3 CO 



o 
in 



CO 
LU. 
O 

cr > 
ok 

LL LU 
CO 



O 




mo® 



c 
z 
5 
CO 





CO 
LU 
>- 



□Bgl(B@ 



LU 

o 
> 



LU 
Q 

o 

o 



- > 



CO 
LU 
ID 

a 

LU 

en 

Q 

CO 
CO 

o 



LU 
CO 

a 

CO 
CO 

=> 



Z3 

a. 
q: cr 

CL LU 
CO 
3 



v 
> 

a: 

LU 
CO 

o 

LL 

2^ 

^3 

LU 

o 
> 



LU 
-J 
LU 



CM 
A 
LL 
-J 

V 

ce 



CO 
LU 

a uj 

LU 

cc 

Q 
CO 
CO 
3 



< 

LU 



Si w 
X s 

< I 

LU -J 

£ ° 

co 

LU = 

«— i cr 

LU LU 
CO h- 

a 2 

UJ uj 
CO >- 
3 CO CQ 



O 
in 



CO 
LU 



m 
o 
in 



II 

h- 
3 

CL 

a: 
lu 

CO 
3 



3 

CO 
LU 
Ql 

CO 
LU 
3 

a 

LU 
K 

Q 
CO 
CO 
3 



co r" 
a a: 

LU < 

Q LU 
CO K 

co 2: 

3 LU 



Q 
LU 



CO 

o 
CO 

a: 

LU 



uj co 

Q^LU 
LU >~ 
CO >- 
3 CQ 



in 



co 

O 

II 

f— 
3 

a 



LU 
CO 
3 



3 

CO 
LU 
IT 

I- 

CO 
UJ 
3 

Of 

LU 

Q 
CO 
CO 
3 



LO 

LL 




SUBSTITUTE SHEET (RULE 26) 



LLI 

O LU 

cr o 

LU ~Z. 



LO 
CD- 
CD 



CD 



CO 
CD 



CO 



LU 



LU 

O. 
< 

LL 
fX 
LU 
I— 



en 

LU 
CO 
3 



f— 
Z) 

O 



Q. 

CO 



CD 
CD 



CD 



a; 



3 

GL 



C/) 

a) 

cb 
ai 



CD 





ILE 






TAB 






"ATE 






r— 

CO 


5 



CO 
LU 
> 



a: 




CO 

q: 
lu 
h- 
co 

o 

LU 



CD 

o 

LL 



LU 



O 
CD 



SUBSTITUTE SHEET (RULE 26) 



FIG. 7a 



User presses \ 
keyK / 



Terminal in 
state S1 



•701 




-703 



The primitive 
corresponding to 
key K in state 
S1 is identified 
and called 



-705 




707 



Service Node 



The called 
primitive 
reports the 
event to SN 



711 



Terminal waits 
for response 



719 



SN analyzes 
the event 



The primitive 
is called 




I 



SN orders a 
call to a 
primitive 



Service Node 



723 




No 



0 



SUBSTITUTE SHEET (RULE 26) 




Request for\ 
a state table V 
S2 / 



735 



Terminal waits 
for response 



r \ 

Service Node 
v J 










) 









•737 



741 



SN downloads 
state table S2 



743 



State S2 is 
entered 




'739 



Service Node 



Information 
of state S2 is 
presented to 
the user 



745 



Terminal in 
state S2 



747 



SUBSTITUTE SHEET (RULE 26) 



FIG. 8 



The event may be an incoming 
call, a new message, etc. 



807 -\ 



809 



The primitive is 
called with 
received 
parameters 




Service Node 



An event 
occurs that 
affects the 

terminal 




801 




SN analyzes 
the event 



'803 



SN orders a 
call to a 
primitive 



(g) 

-805 



Service Node 



New infor- 
mation is 
presented to 
the user 



811 

(e) _ 



E.g. the display is updated 
with the new information 



Terminal in 
state S 



Y 



813 



SUBSTITUTE SHEET (RULE 26) 



FIG. 9 



The event may be an incoming 
call, a new message, etc. 



Terminal in 
state S1 



907 -\ 



909 -\ 



The primitive is 
called with 
received 
parameters 



Service Node 





An ev 
occurs 
affects 

termi 


'ent / 
that / 
;the \ 
nal \ 






SN analyzes 
the event 






/SN orders a 
<^ call to a 
\ primitive 







901 



'903 



'905 



Service Node 



911-\ 



The terminal 
enters state S2 




(c) 



Information 
of state S2 k 
is presented 



(d) n: 



E.g. the display is updated 
with the information of 



Terminal in 
state S2 . 



913 
^915 



state S2 



SUBSTITUTE SHEET (RULE 26) 



FIG. 10a 



1001 



1 



The user turns 
on the terminal 



Terminal 
(turned off) 




The terminal is 
turned on and 
the boot strap 
application 
starts 



1003 




1009^ 



The user 
enters the 
number to SN 



To get a secure connection, 
the "hand-shaking" and 

sending of terminal identity 
may be performed in a 
message dialogue with 

several coded messages. 



The user is 
prompted 
for the num- 
ber to SN 



1005 



Terminal waits 
for user action 



1007 




The terminal 
calls the SN 
through the 
network 



Service Node 



1011 V 



1019 



SN is called and 
answers the call 



A data channel 
is established 
(e.g. a modem 
connection) 



The terminal 
sends an 
application 
request and 
terminal identity 




A' data channel 
s established 
(e.g. a modem 
connection) 



Terminal waits 
for response 



1017 



SUBSTITUTE SHEET (RULE 26) 



FIG. 10b 



1031 



3. 



The user 
enters the 
pass word 



1033 



1035 



Terminal waits 
for response 



The terminal 
identity is used 
to find user data 



-1023 





Request for 
pass word 



1025 



The user is 
prompted 
for pass word 



The prompt to the user may 
either be stored in the 
terminal or sent from the 
Service Node in the request 



1027 
Terminal waits 

for user action A 1029 




The pass word 
is sent to SN 



Terminal waits 
for response 



The pass word 
is checked 





1037 



Acknowledge 
message is 
sent 



1039 



The user is 
asked to wait 
for service 
initiation 



The prompt to the user 
may either be stored in 

the terminal or sent 
from the Service Node 



Terminal waits 
for downloading 



1041 
.1043 



SUBSTITUTE SHEET (RULE 26) 



FIG. 10c 



The indication may be a 
audible and/or a visible 
message stored in the ter- 
minal or sent from the SN 



Terminal waits 
for downloading 



-1043 



r 



1045 




Application 

data are 
downloaded 



Application data 
are stored in 
terminal 



•1017 



Terminal waits 
for downloading 



\ 



1049 




f1051 



The state 
tables are 
downloaded 



The state tables 
are stored 



-1053 



Terminal waits 
for downloading 




r 



1057 



Indicate that 
the application 
is downloaded 




The user is 
indicated that 
the applica- 
tion is ready 



1059 



Terminal waits 
for action 



-1061 



r 



1063 




The user is 
presented the 
information 
of state 1 




Order the 
terminal to 
enter state 1 



Service Node is 

waiting for 
service request 



v. 



Terminal in 
state 1 



1065 



-1069 



SUBSTITUTE SHEET (RULE 26) 



FIG. 11 




SUBSTITUTE SHEET (RULE 26) 




SUBSTITUTE SHEET (RULE 26) 




SUBSTITUTE SHEET (RULE 26) 




SUBSTITUTE SHEET (RULE 26) 




SUBSTITUTE SHEET (RULE 26) 




SUBSTITUTE SHEET (RULE 26) 



c — * 
o o 




SUBSTITUTE SHEET (RULE 26) 



CO 

o d 

'!"! -4— • 

o o 




c 

0 o 




r 1 



SUBSTITUTE SHEET (RULE 26) 



CD 

"(S 
0) 



CO 
CL 



o 

LL 



O 
C/) 

> O CO 

*:j "ca 13 
cttj -a 
c a a 

UJDD 




SUBSTITUTE SHEET (RULE 26) 



CD 

LL 



. o 

LL 

QO , 

GO LU=! 
00q_< 

3 001- 



< 
Q_ 

2 
LU 
Q 

LU 
CL 
LU 
Q 
Z 

LU 

< 

LU 
CQ 



O 



o 
o 

LU 

00 uj 

Q Q 

00 < 

00 UJ 

ZD X 



co — 
c 3 
•-5 oo ro 

o Sfc 

O oo -a 



: 





a: 




LU , 




CD 




i_ 




O 




LL 




LLI 




LL 




O 


CO 




o 






c 






y 


o 




a 




o 




CO 








c 








O 




O 




SUBSTITUTE SHEET (RULE 26) 



1 



o 

oo 



< 

CL 

Z 

LU 
Q 
Z 
LU 
CL 
LU 
Q 



QC 
Lit 
QC 
< 
LU 

m 



i 



O 



o 
o 

LU 
CL 
(J) 

Q 

0) 



DC 
LU 
Q 
< 



C/3 LU 



LU 

m 
o 

LU 
CL 
O 

c 

u. 

O 
O 

o 

CO 

c 
o 

o 



is 



<D 

o 
o 

c 

bo 



t 



c/) 

CO 

i2 
15 
c\j 

i2 
15 
co 




0) - 
O £ £ 

o .E 



c 

CD 

L. 

o 



o 
c 



~ o 
0) E 
o 



CD u 
- (D 
if) 
3 



C 

CD 

E 

CD ^11 II II 

to 5= O t- CNJ CO 



c <D O 



"1^ 

CO 2 o 



SUBSTITUTE SHEET (RULE 26) 



FIG. 19 

Time 

SN IMS 





Invoke (Bind (Appl version)) 
< . 




Begin, Invoke (Process USSD req) 
Result (Bind (Same appl version)) 






. > 

Continue, invoke (USSD req) 

Invoke ("appl dependent ITAP op", GetlmageDescr or Unbind) 
< . — 


Continue, Result (USSD req) 
(ITAP session continues) 

• 
• 
• 





Time 



FIG. 20 



SN 



IMS 



3. 
4. 



Invoke (Bind (Appl version)) 



Begin, Invoke (Process USSD req) 

Result (Bind (New appl version, 
Clear cache, List of images to clear)) 
; 

Continue, Invoke (USSD req) 

Invoke ("appl dependent ITAP op", GetlmageDescr or Unbind) 



Continue, Result (USSD req) 
(ITAP session continues) 



V 



SUBSTITUTE SHEET (RULE 26) 



FIG. 21 



Time 



SN 



1. 
2. 



V 



4. 
5. 



2101 



IMS 



"Call indication" 
Invoke (Bind (Appl version, Incoming call)) 



Begin, Invoke (Process USSD req) 

Result (Bind (Same appl version, aPartylnfo)) 
. . 1 

Continue, Invoke (USSD req) 

Invoke ("appl dependent ITAP op", GetlmageDescr or Unbind) 
< ; ; 



Continue, Result (USSD req) 
(ITAP session continues) 



Time 



SN 



1. 



FIG. 22 



IMS 



V 



Invoke (Bind (Appl version)) 



Begin, Invoke (Process USSD req) 



Error or Reject 



Continue, Invoke (USSD req) 



IMS aborts the 
USSD dialogue 



End, "Empty" 



SUBSTITUTE SHEET (RULE 26) 



Time 



SN 



1. 



FIG. 23 



IMS 



User initiates new session 
or call indication 



2. 
3. 

4. 



(ITAP session 1 in progress, 
optionally wait for result of an 
outstanding ITAP operation) 
Session 1 , Result ("any operation") . 



Continue, Invoke (USSD req) 
< 



Session 2, Invoke (Bind) 



Session 2, Result (Bind) 



Continue, Result (USSD req) 
> 



Continue, Invoke (USSD req) 
Session 2, Invoke ("appl dependent ITAP op", 
GetlmageDescr or Unbind) 



Continue, Result (USSD req) 
(ITAP session 2 continues) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 24 

Time 

SN IMS 



2. 





User initiates new session 
or can inaication 

• 
• 

(ITAP session 1 in progress, 
optionally wait for result of an 
outstanding ITAP operation) 
Session 1 , Result ("any operation") 






— > 

Continue. Invoke (USSD req) 

w O O IWI 1 , 1 1 1 V V-/ f \ w \ LJ 1 1 IU / 

< — — ; 


Continue, Result (USSD req) 

Session 2, Error or Reject f 2401 
. 1. >. 






Continue, Invoke (USSD req) 

Session 1, Invoke ("any operation") 
< 


Continue, Result (USSD req) 
(ITAP session 1 continues) 

• 
• 

i 

• 





SUBSTITUTE SHEET (RULE 26) 



FIG. 25 



SN IMS 





Invoke (Bind (Init. subscription)) 
< — . 




Begin, Invoke (Process USSD req) 
Kesuii ^DinQ ^Application _ o^ni 
version, name of application)) P 






_ — i =► 

Continue, Invoke (USSD req) 

Invoke (Unbind) 
< _ 


MSN closes Continue, Result (USSD req) 
USSD dialogue 

; > 






End, Result (Process USSD req) 



SUBSTITUTE SHEET (RULE 26) 



Time 



SN 



1. 

2. 
3. 

4. 



FIG. 26 



IMS 



(ITAP session in progress) 

Invoke ("appl dependent ITAP op" (arg list)) 

«= __ 

Continue, Result (USSD req) 
Result ("appl dependent ITAP op" (result arg list)) 



Continue, Invoke (USSD req) 

(ITAP session continues) 



2601 



V 



Time 



SN 



FIG. 27 



IMS 



1. 



2. 



V 



(ITAP session in progress) 

Invoke ("appl dependent ITAP op" (arg list)) 



Error or reject J~ 



2yQ^ Continue, Result (USSD req) 



Continue, Invoke (USSD req) 



Depending on the type of error 
the ITAP application in the IMS 
decides if the session should 
continue or be terminated with 

Unbind. 



SUBSTITUTE SHEET (RULE 26) 



* 



FIG. 28 



Time 



SN 



IMS 



1. 

2. 
3. 
4. 



(ITAP session in progress, 
image description for next image is missing in cache) 

Invoke (GetlmageDescr (Image Id)) 
< 

Continue, Result (USSD req) 
Result (GetlmageDescr (Image descr)) 

Continue, Invoke (USSD req) \_ 
(ITAP session continues) 



2801 



FIG. 29 



Time 



SN 



IMS 



1. 

2. 
3. 
4. 



V 



(ITAP session in progress) 

Invoke (GetlmageDescr (Image Id)) 



Error or reject 



2901 



Continue, Result (USSD req) 



Continue, Invoke (USSD req) 



Depending on the type of error 
the ITAP application in the IMS 
decides if the session should 
continue or be terminated with 

Unbind. 



SUBSTITUTE SHEET (RULE 26) 



FIG. 30 



Time 



SN 



IMS 



2. 
3. 



(ITAP session in progress) 



Invoke (Unbind) 



MSN closes 
USSD dialogue 



Continue, Result (USSD req) 
3001 



End, "Empty" or End, Result (Process USSD req) 



V 



FIG. 31 

Time 

SN IMS 



1. 





■ 
• 

(ITAP session 2 in progress) 

Invoke (Unbind (session 2)) 




< . 

2iQ-\ Continue, Result (USSD req) 

"resume ITAP session" 






Continue, Invoke (USSD req) 

Invoke ("appl dependent ITAP op", 
GetlmageDescr or Unbind (session 1 )) 


< ; 

Continue, Result (USSD req) 
(ITAP session 1 continues) 

• 
• 





SUBSTITUTE SHEET (RULE 26) 



FIG.32 

Time 

SN IMS 





■ 

• 

(ITAP session in progress) 

Invoke (Unbind) 

< . 




Continue, Result (USSD req) 

Reject r- 3201 






> 

Continue, Invoke (USSD req) 

IMS aborts 
USSD dialogue 

«= 


End, "Empty" 





SUBSTITUTE SHEET (RULE 26) 



FIG. 33 



Time 



SN 



IMS 



V 



Invoke (Alert (Appl version, Service Id)) 



3301 



Begin, Invoke (USSD req) 

Invoke ("appl dependent ITAP op", GetlmageDescr or Unbind) 
< — 

Continue, Result (USSD req) 
(ITAP session continues) 



Time 



SN 



FIG. 34 



IMS 



3. 



4. 



Invoke (Alert (New Appl version, Service Id)) 



Begin, Invoke (USSD req) 



Invoke (Bind (Old appl version)) 



Continue, Result (USSD req) 

Result (Bind (New appl version, 
Clear cache, List of images to clear)) 

: — — > 

Continue, Invoke (USSD req) 

(ITAP session continues) 



V 



SUBSTITUTE SHEET (RULE 26) 



FIG. 35 



Time 



SN 



1. 
2. 



4. 



Invoke (Alert (New Appl version, Service Id)) J~ 



3501 



IMS 



Begin, Invoke (USSD req) 



Invoke (Bind (Old appl version, Image descr not supported)) 

Continue, Result (USSD req) 

Result (Bind (Old version)) 



Continue, Invoke (USSD req) 

(ITAP session continues) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 36 



Time 



SN 



2. 



3. 



4. 



Invoke (Alert (New ITAP version no)) 



3601 



IMS 



Begin, Invoke (USSD req) 



Invoke (Bind (Old ITAP version no)) 



Continue, Result (USSD req) 
Result (Bind (Old ITAP version no)) 

— =„ 

Continue, Invoke (USSD req) 

(ITAP session continues) 



Time 



SN 



FIG. 37 



1. 



2. 



3. 



Invoke (Alert (New ITAP version no)) 



Begin, Invoke (USSD req) 



3701 



IMS 



Invoke (Bind (Old ITAP version no)) 



Continue, Result (USSD req) 



MSN closes 
USSD dialogue 



3703 



End, "Empty" 



SUBSTITUTE SHEET (RULE 26) 



FIG. 38 



Time 



SN 



1. 

2. 
3. 



V 



Invoke (Alert (Appl version, Service Id)) 



3801 



IMS 



Begin, Invoke (USSD req) 



MSN closes 
USSD dialogue 



End, "Empty" 



3803 



Error or Reject 



Continue, Result (USSD req) 



Time 



FIG. 39 



SN 



1. 

2. 

3. 
4. 



V 



Invoke (Alert (New Appl, Service Id)) 



Begin, Invoke (USSD req) 



IMS 



Invoke (Bind (Old appl version)) 



Continue, Result (USSD req) 



Error or Reject 



3901 



Continue, Invoke (USSD req) 



IMS aborts 
USSD dialogue 



End, "Empty" 



SUBSTITUTE SHEET (RULE 26) 



FIG. 40 

Time 

SN IMS 



1. 





• 
• 
• 

(No ITAP session in progress 
or 

ITAP session in progress) 

Invoke (Bind, "appl dependent ITAP op" or GetlmageDescr) 
< _ 




Begin, Invoke (Process USSD req) 
or Continue Result fUSSD rpn^ 

Result, Error or Reject C 4001 






: — > 

Continue, Invoke (USSD req) 

| IMS can t interpret 
4003 < the reply from SN 
4005 Properly: 
J~ r '""""' Invoke (Unbind) 
< i £ 


Continue, Result (USSD req) 

• 

(Unbind scenario continues) 





SUBSTITUTE SHEET (RULE 26) 



FIG. 42 



Time 



1. 
2. 

3. 



SN 4201 IMS 

(Header, seg flag = more to come, operation 1:st part) 



V 



Begin, Invoke (USSD req) 



(Header, seg flag = get more info) 



Continue, Result (USSD req) 
(Header, seg flag = no more info, operation 2:nd part) 



Continue, Invoke (USSD req) \_ 
(ITAP session continues) 



4203 



Time 



FIG. 43 



SN 



IMS 



1. 



3. 



4. 



V 



(ITAP session in progress) 



(Header, seg flag = more to come, 
result operation 1 :st part) 



4301 



Continue, Invoke (USSD req) 

(Header, seg flag = get more info) 



Continue, Result (USSD req) 
(Header, seg flag = no more info, result operation 2:nd part) 



Continue, Invoke (USSD req) 

(ITAP session continues) 



4303 



SUBSTITUTE SHEET (RULE 26) 



FIG. 44 

IMS 



• 

(ITAP session in progress) 
• 

"Any operation invoked by the IMS" 
- 




4401 < 


Continue, Result (USSD req) 

' IMS detects timeout, 
all ITAP sessions are aborted 




T — 

u 4403 


End, "Empty" 





FIG. 45 



IMS 

4501 

Invoke (Bind) 
Begin, Invoke (Process USSD req) 



j IMS detects timeout, 

4503 < local abort of ITAP session 
\ and USSD dialogue 



SUBSTITUTE SHEET (RULE 26) 



Time 



SN 



FIG. 46 



IMS 



(No ITAP session in progress 
or 

ITAP session in progress) 



2. 
3. 
4. 



5. 

6. 



Invoke (Bind, "appl dependent ITAP op" or GetimageDescr) 



Result 



Begin, Invoke (Process USSD req) 
or Continue, Result (USSD req) 
: > 



Continue, Invoke (USSD req) 



4601 



4605 



"No user input so IMS detects idle timeout, 
only this ITAP session is terminated" 

Invoke (Unbind) 



4603 



Continue, Result (USSD req) 



(Unbind scenario continues, i.e. 
USSD dialogue is closed or 
a previously interrupted 
session is resumed) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 47 



Time 



V 



SN 



IMS 



2. 



3. 
4. 



Invoke Alert (Appl version, Service Id) 



Begin, Invoke (USSD req) 



4705 



MSN closes 
USSD dialogue 



End, "Empty" 



4701 



No user input so 
„ IMS detects timeout, 
4703 {jTAP session is terminated 
Invoke (Unbind) 



Continue, Result (USSD req) 



Time 



FIG. 48 



SN 



IMS 



V 



(No ITAP session in progress 
or 

ITAP session in progress) 
Invoke (Bind, "appl dependent ITAP op" or GetlmageDescr) 



Result, Error or Reject 



Begin, Invoke (Process USSD req) 
or Continue, Result (USSD req) 



Continue, Invoke (USSD req) 



No operation invoked from IMS I 
so MSN detects idle timeout. J 
All ITAP sessions are aborted. 



4801 



} 4803 



4805 



Abort, "Empty" 



SUBSTITUTE SHEET (RULE 26) 



FIG. 49 



Time 



SN 



Invoke Alert 



Begin, Invoke (USSD req) 



4901 



IMS 



V 



No operation invoked from IMS 
so MSN detects idle timeout 

Local abort of ITAP session "\ 
and USSD dialogue f 



>. 4903 



4905 



SUBSTITUTE SHEET (RULE 26) 



FIG. 50 



Time 



SN 



1. 

2. 
3. 



4. 
5. 

6. 



ITAP session in progress 
ITAP operation result 

Continue, Invoke (USSD req) 



5001 



IMS 



Timer in IMS 
expires 

"dummy req" 



"dummy cont" 



Continue, Result (USSD req) 
, > 



Continue, Invoke (USSD req) 



(ITAP session continues) 



V 



I 



SUBSTITUTE SHEET (RULE 26) 



FIG. 51 



Time 



SN 



IMS 



1. 

2. 
3. 



6. 



7. 



8. 



ITAP session in progress 
Result ("appl dependent ITAP op") 

Continue, Invoke (USSD req) 



r 



5101 



Timer in IMS 



5103 



^ expires 
"switch USSD dialogue req" 



Continue, Result (USSD req) 
5105 



"switch USSD dialogue confirm" 



End, Result (ProcessUSSDReq) 



5107 



The mobile initiated USSD dialogue has been terminated. \j 
A new, network initiated USSD dialogue, is set up. J 



5109 



"resume ITAP session" 



Begin, Invoke (USSD req) 

(ITAP session continues) 



V 



SUBSTITUTE SHEET (RULE 26) 



FIG. 52 



Time 



SN 



2. 



4. 
5. 



7. 



8. 



V 



IMS receives an indication of new incoming call. 
The call is confirmed and alert is returned 



IMS 



- 5201 



5203 Bind invoke (Appl version, incoming call) 



Begin, Invoke (Process USSD req) 
Bind result (Appl version, Sen/ice Id, A-Party Info) r- 5205 



Continue, Invoke (USSD req) Connect message js sent 
and the speech connection is established 



5207 



AcceptCall invoke 



Continue, Result (USSD req) 



AcceptCall result 



r 



5209 



Continue, Invoke (USSD req) 
Unbind invoke () 



Continue, Result (USSD req) 



"Empty" 



End, Result (Process USSD req) 



□ 



SUBSTITUTE SHEET (RULE 26) 



FIG. 53 



Time 



1. 



2. 



SN IMS 

IMS receives an indication of new incoming call. 
The call is confirmed and alert is returned 

5301 

f 5303 Bind invoke (Appl version, incoming call) 
< ■ — — 



8. 



Begin, Invoke (Process USSD req) 
Bind result (Appl version, Service Id, A-Party Info) r- 5305 



Continue, Invoke (USSD req) 



5307 RejectCall invoke 



Continue, Result (USSD req) 
The MSN disconnects the call leg to the IMS. 



RejectCall result 



Continue, Invoke (USSD req) 



Unbind invoke () 



Continue, Result (USSD req) 



"Empty" 



End, Result (Process USSD req) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 54 



Time 



SN IMS 

IMS receives an indication of new incoming call. 
The call is confirmed and alert is returned 



2. 



5. 



6. 



8. 



10. 



5401 



5403 Bind invoke (Appl version, incoming call) 



Begin, Invoke (Process USSD req) 
Bind result (Appl version, Service Id, A-Party Info) r- 5405 



Continue, Invoke (USSD req) 



RetrieveRoutingList invoke 



Continue, Result (USSD req) 
The MSN disconnects the call leg to the IMS. 

<: = = = = = = r = = = = = = r = = r = r = = = = = = = = r = r = = = = r = = = = = = = = -> 



RetrieveRoutingList result 



Continue, Invoke (USSD req) 

r 5407 TransferCall invoke (Forward to number) 



Continue, Result (USSD req) 



TransferCall result 



Continue, Invoke (USSD req) 



Unbind invoke () 



"Empty" 



Continue, Result (USSD req) 
> 



End, Result (Process USSD req) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 55 



Time 



1. 



IMS receives an indication of new incoming call. 
The call is confirmed and alert is returned 

5501 

j~ 5503 Bind invoke (Appl version, incoming call) 



4. 

5. 
6. 



8. 



9. 



10. 



11. 



Begin, Invoke (Process USSD req) 
Bind result (Appl version, Service Id, A-Party Info) j- 5505 



Continue, Invoke (USSD req) 
^ y- 5507 



HoldCall invoke 



Continue, Result (USSD req) 



HoldCall result 0 



Continue, Invoke (USSD req) 



Connect message is sent and the 
speech connection is established 



znzzzzzzzznzzzzz22zzzzzznzzzzzzz2zzzzzzz znz2znnzzzzzzzzzz2i 



5509 



AcceptCall invoke 



Continue, Result (USSD req) 



AcceptCall result 



Continue, Invoke (USSD req) 



Unbind invoke () 



"Empty" 



Continue, Result (USSD req) 
> 



End, Result (Process USSD req) 



□ 



SUBSTITUTE SHEET (RULE 26) 



FIG. 56 



Time 



1. 



2. 
3. 
4. 



SN IMS 
IMS receives an indication of new incoming call. 
The call is confirmed and alert is returned 

5601 

j~ 5603 Bind invoke (Appl version, incoming call; 



6. 



7. 



8. 



V 



Begin, Invoke (Process USSD req). 

Bind result (Appl version, Service Id, A-Party Info) r- 5605 

> 



Continue, Invoke (USSD req) 



j- 5607 CallBack invoke 



Continue, Result (USSD req) 
The MSN disconnects the call leg to the IMS. 



CallBack result 



Continue, Invoke (USSD req) 



Unbind invoke () 



Continue, Result (USSD req) 



"Empty" 



End, Result (Process USSD req) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 57 



Time 



SN 



IMS 



3. 

4. 
5. 



6. 



7. 



8. 



9. 



10. 



11. 



V 



(ITAP session 1 in progress) 
"any operation" result (Session 1) 



5701 



Continue, Invoke (USSD req) 

IMS receives an indication of new incoming call. 

The call is confirmed and alert is returned j- 5703 

r~ 5705 Bind (Session'2, Incoming call) invoke 



Continue, Result (USSD req) 

Bind result (Session 2, Service Id, A-Party Info) r- 5707 
_Z > 

Continue, Invoke (USSD req) 

Connect message is sent 
and the speech connection is established 



^777 



AcceptCall invoke (Session 2) 



Continue, Result (USSD req) 



AcceptCall result (Session 2) 



5709 



Continue, Invoke (USSD req) 
Unbind (Session 2) invoke 



"Resume ITAP session" 



Continue, Result (USSD req) 

r 5711 . 



Continue, Invoke (USSD req) 

(ITAP session 1 continues) 



□ 



SUBSTITUTE SHEET (RULE 26) 



FIG. 58 



Time 



SN 



1. 



3. 

4. 
5. 
6. 
7. 



5801 IMS 
Bind invoke (Appl version, User initiated) 



Begin, Invoke (Process USSD req) 

Bind result (Messaging Profile Management) 

^ 

Continue, Invoke (USSD req) 



J 



5803 MailboxStatus invoke (All media) 



Continue, Result (USSD req) 



MailboxStatus result 



Continue, Invoke (USSD req) 

5805 EnquiryMailbox invoke (Voice media, New msg) 



Continue, Result (USSD req) 



EnquiryMailbox result 



Continue, Invoke (USSD req) 



(ITAP session continues) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 59 



Time 



SN 



IMS 



1. 



2. 



6. 



8. 



10. 
11. 
12. 



(ITAP session in progress) 
5901 PlayMessage invoke (Message ld t all) 



Continue, Result (USSD req) 

IMS receives an indication of new incoming call. 

The call is confirmed and alert is returned j~ 5903 

PlayMessage result (speech connection is allocated) 



Continue, Invoke (USSD req) 



5905 



Connect message is sent and the speech connection is 
established between IMS and MSN. 



EnquiryCallSetUpStatus invoke () 



Continue, Result (USSD req) 
EnquiryCallSetUpStatus result (Connected to voice mail) 



Continue, Invoke (USSD req) 



The playing of the voice messages 
are managed with DTMF 



5907 



5909 



ReleaseResource invoke 



Continue, Result (USSD req) 
The MSN disconnects the call leg to the IMS. 

<t:r::::: = z = ::r:::r::::::r:::::.":::: = :::::::» 

ReleaseResource result () 



Continue, Invoke (USSD req) 

(ITAP session continues) 



□ 



SUBSTITUTE SHEET (RULE 26) 



FIG. 60 



Time 



SN 



IMS 



5. 



7. 
8. 
9. 



TZZnEZZ22Z2ZZZZZZZZZZZttZZZZZZZnZZZnZZZZZZZZZZZZ ZZZZZZZZZZZl 



(ITAP session in progress) 
" 6001 SetUpCall invoke (Number) 

Continue, Result (USSD req) 

IMS receives an indication of new incoming call. 
The call is confirmed and alert is returned 



SetUpCall result () 



Continue, Invoke (USSD req) 

Connect message is sent and the speech connection 
is established between MSN and IMS. 



EnquiryCallSetUpStatus invoke () 



Continue. Result (USSD req) 
EnquiryCallSetUpStatus result (B-part has answered) 



Continue, Invoke (USSD req) 



Unbind invoke 



"Empty" 



Continue, Result (USSD req) 
> 



End, Result (Process USSD req) 



SUBSTITUTE SHEET (RULE 26) 



FIG. 61 



Time 



SN 



IMS 



3. 

4. 

5. 
6. 

7. 

8. 



10. 



Bind invoke (Appl version, User initiated) 



Begin, Invoke (Process USSD req) 
Bind result (Messaging Profile Management) 



Continue, Invoke (USSD req) 



MailboxStatus invoke (All media) 



Continue, Result (USSD req) 



MailboxStatus result 



Continue, Invoke (USSD req) 

6101 EnquiryMailbox invoke (Fax media, New msg) 



EnquiryMailbox result 



Continue, Result (USSD req) 
6103 ^ 



Continue, Invoke (USSD req) 

6105 — \ SendMessage invoke (Message Id, Fax) 
«= — 

Continue, Result (USSD req) 
SendMessage result (Message sent) 6107 



Continue, Invoke (USSD req) 



ReleaseResource invoke 



Continue, Result (USSD req) 



ReleaseResource result 



Continue, Invoke (USSD req) 



11 



(ITAP session continues) 



V 



SUBSTITUTE SHEET (RULE 26) 



FIG. 62 



SN . IMS 





• 

(ITAP session in progress) 

6201 RetrieveRoutingTable invoke (Routing table Id) 
< ^ — — 




Continue, Result (USSD req) 

RetrieveRoutingTable result 6203 -\ 
: ^ > 






Continue, Invoke (USSD req) 

6205 RetrieveRoutingList invoke (Type = Routing List) 
< — 


Continue, Result (USSD req) 

RetrieveRoutingList result 6207 -\ 
: > 






Continue, Invoke (USSD req) 

6209 -\ UpdateRoutingTable invoke 
< , 


Continue, Result (USSD req) 
UpdateRoutingTable result 621 1 '-\ 

L- ^ > 






Continue, Invoke (USSD req) 

(ITAP session continues) 

• 
• 



SUBSTITUTE SHEET (RULE 26) 



FIG. 63 

Time 

SN IMS 





• 
• 

(ITAP session in progress) 

6301 RetrieveNameOfRoutingTables invoke 
< — — 




RetrieveNameOfRoutingTables result 6303 — \ 
^ > 






Continue, Invoke (USSD req) 

j 6305 -\ SetActiveRoutingTable invoke (Routing table Id) 
< ~ . 


Continue, Result (USSD req) 

SetActiveRoutingTable result 






. , ^ 

Continue, Invoke (USSD req) 

(ITAP session continues) 

• 



SUBSTITUTE SHEET (RULE 26) 



FIG. 64 

Time 

SN IMS 





Alert invoke (New Message) 6401 ~a 
— ■ > 






Begin, Invoke (USSD req) 

6403 -a RetrieveNewMessagelnfo invoke 
< ^— . 


Continue, Result (USSD req) 
RetrieveNewMessagelnfo result 

(Number of msgs, originator, media, timestamp) j— 6405 






> 

Continue, Invoke (USSD req) 

6407 ~^ EnquiryMailbox invoke (voice media, New msg) 


Continue, Result (USSD req) 

EnquiryMailbox result 6409 — > 
^ > 






Continue, Invoke (USSD req) 

(ITAP session continues) 

• 

_ 



SUBSTITUTE SHEET (RULE 26) 



IPC 6" "H04Q7/2T 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 6 H04Q 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and. where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



-/-- 



I X| Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



J Special categories of cited documents : 

A" document defining the general state of the art which is not 
considered to be of particular relevance 

"E" earlier document but published on or after the international 
filing date 

V document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

M 0" document referring to an oral disclosure, use. exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

"&" document member of the same patent family 



Date of the actual completion of theinternationai search 



5 March 1998 



Date of mailing of the international search report 

17/03/1998 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



Clchra, M 



Form PCT/ISA/210 (second sheet) (July 1992) 



page 1 of 3 



I W DC nCLCYMfl I 



Category : 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



Y 
A 



WO 96 20572 A (ERICSSON TELEFON AB L M) 4 
July 1996 



see abstract 



see figures 1,3,6 



see page 1, line 1-19 

see page 3, line 2-14 

see page 4, line 1 - page 5, line 15 

see page 8, line 6-12 

see claim 1 

EP 0 717 570 A (SIEMENS AG) 19 June 1996 



see abstract; figure 1 



see column 1, line 1 - column 2, line 7 
see column 2, line 42-52 
see column 3, line 23-41 
see claims 1,2 

DE 195 20 632 A (SIEMENS AG) 19 December 
1996 



see abstract; figure 1 



see column 1, line 1-14 
see column 2, line 55-59 
see claims 1-3 

-/-- 



1-5,9, 

11,12, 

14,15, 

27,30, 

34,36, 

45,56,65 

22,24, 

26,29, 

33,35, 

37,44, 

46,52, 

57,64,71 

6-8,10, 

13,23, 

25,28, 

31,32, 

38-43, 

47,48, 

51,55, 

58-63, 

66,67,70 



1-3,6,7, 

11,12, 

15,30 

5,9,13, 

14,31, 

32,36, 

45,56,65 



1-3,6,7, 

11,12, 

15,30, 

44,46,64 

13,14, 

29,31, 

32,36,56 



Form PCT/ISA/210 (continuation ol second sheet) (July 1992) 



page 2 of 3 



umiiwhi/ tswvunrtcn I O V/UllOll/CnCU lUOCnCLCVMNI 



Category : 



Citation of document, with Indication, where appropriate, of the relevant passages 



Relevant to daim No. 



P.Y 
A 



HELLAKER J ET AL: "REAL-TIME TRAVELLER 
INFORMATION - IN EVERYONE'S POCKET? - A 
PILOT TEST USING HAND-PORTABLE GSM 
TERMINALS- 
PROCEEDINGS OF THE VEHICLE NAVIGATION AND 
INFORMATIONS SYSTEMS CONFERENCE, OTTAWA, 
OCT. 12 - 15, 1993, 
no. -, 12 October 1993, REEKIE H M, 
pages 49-52, XP000448510 
see the whole document 



EP 0 772 367 A (SIEMENS AG) 7 May 1997 
see abstract; figure 1 



see column 1, line 1 - column 2, line 47 
see claim 1 

KYLANPAA , P ILHAJAMAA , BERGENWALL : "Nomadic 

access to information services by a GSM" 

COMPUTER & GRAPHICS, 

vol. 20, no. 5, 1 September 1996, 

pages 651-658, XP002039641 

see the whole document 

REINHARDT A: "THE NETWORK WITH SMARTS NEW 
AGENT-BASED WANS PRESAGE THE FUTURE OF 
CONNECTED COMPUTING" 
BYTE, 

vol. 19, no. 10, 1 October 1994, 

page 51/52, 56, 58, 60, 62, 64 XP000480909 

see the whole document 



29,33, 
35,52,71 



1-5, 

9-15,30, 

34,36, 

42,44, 

45,56, 

64,65 

22,24, 

26,37,57 

1-4,11, 

25,29, 

30,34, 

36, 

38-43, 
56,58-63 



I- 7, 

II- 15, 
29,30, 
36,45, 
46,56,65 



1-26,30, 
34, 

36-47,51 



1 



Forni PCT/IS/U21 0 (continuation ot second sheet) (July 1 992) 



page 3 of 



3 



Pa font Hnnimant 

cited in search report 


Pnhliratinn 

r UUIIlsClllVI l 

date 


Patent family 
member(s) 


Publication 
date 


WO 9620572 ,A 


04-07-96 


AU 4358696 A 
CA 2208415 A 
EP 0799553 A 
FI 972667 A 


19-07-96 
04-07-96 
08-10-97 
21-08-97 


EP 0717570 A 


19-06-96 


FI 955956 A 


13-06-96 


DE 19520632 A 


19-12-96 


NONE 




EP 0772367 A 


07-05-97 


NONE 





Form PCT/lSA/210 (patent tamOy annex) (July 1992) 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 
□TfaDED TEXT OR DRAWING 
^BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



